DELIVERABLE D.A3.1 SoA on Ontologies and the Ontology

DELIVERABLE D.A3.1 SoA on Ontologies and the Ontology
Programme
Integrating and Strengthening the European Research
Strategic Objective
Networked businesses and governments
Integrated Project / Programme Title
Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks
and their Application
Acronym
ATHENA
Project No
507849
ATHENA – Project Name
Knowledge Support and Semantic Mediation Solutions
ATHEN A - Project No
A3
DELIVERABLE D.A3.1
Title
SoA on Ontologies and the Ontology Authoring
and Management System, with Ontology
Modelling Language.
Summary
Leading Partner: CNR-IASI
Security Classification: Project Participants (PP)
March 31st, 2005
Version 1.0
P- Project
ATHENA Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
507849
04.04.05
Deliverable process schedule
No
1
2
3
4
5
Process step
Responsible
Initial drafting of the deliverable
including structure, comments and first F. Taglino (CNR)
basic content to be sent to to-beM.Missikoff (CNR)
contributors.
F.Taglino (CNR)
First round of contributions. Work
package member and others to
D. Gazzotti
contribute first iteration to owner of
(Formula)
the deliverable
S-M Thomas (SAP)
Owner to consolidate first round input
F. Taglino (CNR)
and distribute to contributors
F.Taglino (CNR)
L. Pondrelli
Final round of contributions including
(Formula)
comments form peers/AL to be sent to
S-M Thomas (SAP)
owner
E. Coscia (TXT)
F.W. Jaekel (IPK)
F. Taglino (CNR)
Final consolidation of input and
finalisation of “technical” document to
M. Missikoff (CNR)
be send to
G. Callegari (CNR)
Timing
05.07.2004
27.08.2004
22.10.2004
14.01.2005
28.01.2005
6
Quality check – e.g. Peer Review
Elmar Dorner (SAP)
14.03.2005
7
Final editing
26.07.2005
8
Final Approval from partners or
delegates to be send to Programme
Office
9
Submission to Commission
Programme office
PCC members or
delegates: Guy
Dougmeings (itrec)
Joerg Muller
(Siemens)
Programme Office
050404_ATHENA_DA31_Summary_v10.doc
Comments
Only part B has been revised. We
didn’t receive any feedback for Part A
and B.
21.03.2005
31.03.2005
04.04.2005
CONFIDENTIAL
Page ii / 244
P- Project
ATHENA Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
Table of contents
1
Summary of Deliverable A3.1
1
2
Executive Summary
2
3
Extended summary of DA3.1 Deliverable.
3
3.1
DA3.1 Part A Summary: The State of the Art on Ontology
3.1.1
Ontology modelling languages
3.1.2
Ontology related software systems
3.1.3
Ontology content
3.1.4
Relationship between the Interop and the Athena SoA
3
3
4
6
7
3.2
DA3.1-B Summary. Athos technical Specifications
3.2.1
The representational specifications of Athos
3.2.2
The functional and architectural specifications
7
7
8
3.3
DA3.1-C Summary. The User Manual of Athos
8
3.4
Conclusions
9
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page iii / 244
P- Project
ATHENA Project
Document
1
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
Summary of Deliverable A3.1
This summary is organised in a first Executive Summary, followed by three specific Summaries,
one for each of the three parts in which the Deliverable is divided.
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page 1 / 244
P- Project
ATHENA Project
Document
2
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
Executive Summary
The Deliverable D.A3.1 is the first official outcome of the A3 Project – Knowledge Support and
Semantic Mediation Solutions. The deliverable is composed of three parts, released as separate
documents, and a software system:
•
D.A3.1 Part A - The State of the Art on Ontologies, addressing ontology languages, tools and
existing ontology contents in the area of eBusiness;
•
D.A3.1 Part B - The specifications of the ontology management system Athos, with its
representational and functional features;
•
D.A3.1 Part C - The User Manual of the ontology management system Athos;
•
Software system - the ontology management Athos 1.0. This is the first version of the system,
version Athos 2.0 is due at month 20.
DA3.1 Part A – The State of the Art on Ontologies
This part gathers the results of the work concerning the State of the Art (SoA). The SoA has been
focused on the following topics.
•
Ontology modelling languages
•
Ontology related software systems
•
Ontology content
At the end of this part, a number of considerations are reported, as well as the indications of the
characteristics most suitable for the development of the Athena Semantic Solutions.
DA3.1 Part B – The Athos Specifications
This part of the Deliverable describes the specifications of Athos, the Athena ontology
management system.
•
•
There are two main aspects that are covered:
the representational specifications, essentially the description of OPAL, the ontology modelling
methodology that leads the ontology construction in Athos (from Section 2 to Section 8);
the technical specifications, that regard the architectural and implementation issues (from Section
9 to Section 14).
DA3.1 Part C – The Athos User Manual
This part of the Deliverable consists in the Athos User Manual. The manual is conceived in order
to allow a user with a limited competency in ontologies to interact with the system and build a domain
ontology.
In order to reduce the amount of propaedeutic knowledge required when one wishes to use the
Athos system, the User Manual starts with a brief recap on the OPAL meta-model. Then the main
functions of the system are illustrated, organised according the two key roles: Ontology User, with
limited privileges, essentially read-only, and Ontology Master, who has all the prerogatives in acting on
the ontology content and the management of the users. There is also the role of Admin, that has the
rights to create a new ontology, delete an existing one, etc. Finally, the two main modalities of Athos
are described: the Glossary Mode, with limited modelling capabilities, and the Ontology mode, with full
modelling capabilities.
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page 2 / 244
P- Project
ATHENA Project
Document
3
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
Extended summary of DA3.1 Deliverable.
3.1
DA3.1 Part A Summary: The State of the Art on Ontology
A document on the State of the Art has a primary goal of acquiring a clear and up to date
understanding of the recent achievements in a given sector. In particular, in our case, we needed to
investigate on what is available in terms of current, most advanced ontology-based solutions.
Furthermore, in the Athena IP, we also intended to use the SoA on ontologies to understand to what
extent existing achievements can be used for our purposes and where we have to develop original, ad
hoc, solutions.
The SoA document is organised into three sections, to address in a clear and distinct way the
fundamental issues concerning ontologies in the perspective of the Athena IP: (1) Ontology modelling
languages, (2) Ontology management systems, Inference engines, EAI platforms, (3) Ontology
content. Please note that we addressed also EAI platforms since they are direct competitors of the
ontology-based services we intend to develop for interoperability and, recently, they are starting to
enrich their functionalities with semantic capabilities.
3.1.1
Ontology modelling languages
This section reports a survey of the most relevant languages used to model ontologies. The
section starts with the identification of the main criteria that allow each analysed language to be quickly
characterised. The languages have been organised into families, to group them on the basis of their
most prominent characteristics. We have identified the following families of languages:
•
Diagrammatic languages
•
Frame-oriented languages
•
Logic-based languages
•
Web-oriented languages
•
Process-oriented languages
During the work on the SoA numerous issues were raised. One concerns the possibility of
considering, in the SoA, only ontology languages usually accepted by the ontology community, or to
broaden the survey to other modelling languages, developed in other contexts, where conceptual
modelling is necessary (from Software Engineering to database design, from BP modelling to
Enterprise Engineering). In the literature there is not a clear separation of ontology languages from
other conceptual modelling languages. The ontology research field is still in its infancy and requires to
be consolidated. Some times, the debate addresses the problem of identifying what can be properly
considered as an ontology with respect to other repositories of abstract models, such as: a thesaurus,
a glossary, a data dictionary, a knowledge base. However, in order to restrict our analysis, adopting
the position that privileges for an ontology language a formal basis, and some reasoning techniques
associated to it. (But in the SoA, some relevant languages have been included that do not meet this
requirement.)
As anticipated, the ontology languages have been analysed using a set of predefined criteria,
concerning the basic constructs to define: concepts, attributes, relations, instances, formal properties
of attributes and relations, possible restrictions (e.g., on domain/range, on multiplicity) over them.
Conclusions and gap analysis - In the field of ontology languages there is an important debate
about the expressiveness of a language and the computational complexity exhibited by the related
services (essentially, the inference methods). Currently, the proposal that is gaining momentum is the
Ontology Web Language OWL, proposed by W3C. Such a language has a strong rooting in the formal
work achieved in Description Logics and, therefore, has a limited expressive power but the possibility
of developing effective (and complete) reasoning engines.
In the work of the A3 Project, we decided to adhere to the OWL proposal, but introducing some
enhancements due to its lack of domain specificity for the business domain.
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page 3 / 244
P- Project
ATHENA Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
In terms of requirements for Athena, there are three major features that we need to find in an
ontology modelling language:
•
formal basis, and availability of inference engines capable of reasoning over ontology content;
•
business-oriented constructs, to facilitate the construction of business ontologies (business
domain specificity)
•
expressive power, sufficient to model some characteristics related to process ontologies (e.g.,
precedence relation, conditionals to represent pre- and post-conditions).
None of the analysed languages presents at the same time the three above features. For this
reason, to fill this gap, we propose in Athena to use OPAL (Object, Process, Actor modelling
Language), which is the ontology modelling method based on OWL and enriched with specific
constructs. This issue is more widely elaborated in the document D.A3.1-B. There, a more extensive
list of requirements are presented, and some specifications of the proposed solutions are outlined.
3.1.2
Ontology related software systems
In this section we analyse the main software systems aimed at the development of ontologies and
at reasoning over them. Here we also address the current leading technology for interoperability: EAI,
mentioning their evolution towards semantic services.
Ontology management systems
This section surveys the most relevant OMS available on the market. Those are essentially
experimental solutions, mainly developed by academic groups. The most relevant OMS have been
analysed, by using a common set of criteria. Such criteria consider several important elements, such
as: the language used to model ontologies, the possibility of representing instances, the query
facilities, the web-orientation. A detailed list and explanation of the criteria used for the analysis can be
found at the beginning of Section 2 of this document.
The analysis started with a broad number of OMS, that was rapidly reduced to the most relevant
subset, in the perspective of the Athena IP. Such list includes:
•
KAON
•
Protégé
•
pOWL
•
Ontolingua (with Chimera)
•
OilEd
Conclusions and gap analysis. The requirements for the OMS of Athena have two main aspects,
one is its ontology representation method and the other is the key architectural features. For the
representation method we wanted to meet the domain specificity already introduced in the Section on
Ontology modelling languages (see OPAL issue). For what concerns the architectural features, the
main requirements, besides the most common ones (such as graphical user interface, import/export,
query facilities, instance handling) were: web application, with an extensive shared and distributed
usage possibility; log facility, to keep under control the activities of each user; possibility of integration
with a Glossary, for a more versatile, easy use of the terminological component of an ontology, web
service enabled, with a double role: to invoke web services and to publish ontology management
functions as a web service.
The reported analysis shows that the system that is getting closer to our requirements is pOWL.
However, there are a number of requirements for which pOWL does not show the needed
functionalities (please see the table of Sect 3.4). For these reasons we decided to develop Athos
(Athena Ontology System). Furthermore, Athos represents the most up to date version of a number of
ontology managers developed at LEKS in the last decade, capitalising therefore the experience and
the know-how acquired in previous important projects.
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page 4 / 244
P- Project
ATHENA Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
Inference engines
Reasoning facilities are a key element of a semantics-based solution. One of the main motivations
for using formal ontologies is the possibility of reasoning over the stored conceptual expressions. In
particular, in Athena, reasoning will be used for two major purposes: (i) consistency checking, to verify
that the ontology (and the semantic annotations, addressed in the second phase of the project) is free
of contradictions; (ii) rule-based productive reasoning, to achieve runtime interoperability when two or
more (heterogeneous) enterprise software applications need to cooperate. The latter is achieved by
means of a set of reconciliation rules that allow different messages to be transformed.
•
•
•
•
•
In the survey, five of the most relevant inference engines have been analysed:
Jess
Jena2
Racer
Metalog
SWAP/CWM
Conclusions and gap analysis. The analysis of the State of the Art revealed the high complexity of
an artefact like an inference engine and the high level of specialization exhibited by the groups working
on this matter. These elements, joined to the existence of a large community that produced good
results in the last period (and the limited resources available to this end in the Athena project),
convinced us of the opportunity not to develop a new reasoner, but to acquire and adapt one (or more)
existing engine. The survey revealed that the existing engines are somehow specialised either towards
“truth maintenance” (i.e., consistency checking) or towards production reasoning. In the first category
the most relevant appears to be Racer, while for the second Jena2. This problem is widely known in
the community and, for this reason, the team of Jena2 developed an adapter (based on a specific
interchange format, named DIG) to create a tight cooperation with Racer. As a conclusion, we decided
to investigate more extensively on the possibility of jointly using Racer and Jena2 for consistency
checking and runtime reconciliation, respectively. For the latter objective, a comparison analysis will be
performed to contrast the performances of Jena2, based on RDF-like rules, against solution based on
rules modelled by using XSLT.
Enterprise Application Integration (EAI) platforms
In this State of the Art we decided to include the analysis of the most advanced, among the
industrial-strength, current technology solutions conceived to solve interoperability problems among
enterprise software applications: Enterprise Application Integration platforms. Current EAI
implementations do not make use of ontology-based solutions, nevertheless they represent in many
situations a valuable approach to solve interoperability problems. In the perspective of a better
understanding of pros and cons of EAI, and to contrast such a technology with semantics-based
solutions, we decided to include this part in the SoA.
As emerges from the study, today there are many competitors in the EAI market, and it is even
difficult to draw a precise boundary to identify them from other products, such as workflow or
cooperation platforms, that provide some functionalities to support interoperability solutions. Within
such a rich context, we decided to focus on the market leaders (according to Gartner Group), that also
present the richer set of functionalities.
•
IBM WebSphere Business Integration
•
MS BizTalk
•
TIBCO
•
WebMethods
•
SeeBeyond
•
SEA WebLogic
•
SAP Netweaver
Conclusions and gap analysis – EAI platforms represent an important technological advancement,
with respect to the past “ad hoc” approach to enterprise software application (ESA) interoperability. In
fact, while an “ad hoc” solution requires the development of an adaptor (essentially a piece of
software) for each pair of applications needing to communicate, an EAI solution is based on a central
hub (or software bus) capable of interconnecting the different ESAs with a centralised set of adapters.
Furthermore, the logics of the adapters, for the runtime reconciliation of messages, is expressed with a
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page 5 / 244
P- Project
ATHENA Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
rule language, instead of being coded in a programming language. However, the basic philosophy
requires that the reconciliation logics is implemented for each pair of communicating applications,
leading to the geometrical explosion of the number of adapters to be implemented.
The semantic interoperability approach intends primarily to reduce the problem of the geometrical
growth of the adapters, creating a common understanding of the business scenario (by means of a
reference ontology) and unifying the reconciliation adapters to such a common scenario. We believe
that semantic interoperability is not the panacea that will solve all possible interoperability problems in
all possible situations. We believe that it will contribute to solve a good number of problems, but there
will be still a number of cases where good “traditional” technology will perform well, or even better.
Since the construction of a common business scenario does not come without a cost, we believe that
there are cases where more traditional solutions (EAI, but even “ad hoc” for simple cases) will be a
better choice, even in presence of a successful semantic interoperability solution.
Finally, the EAI sector is gaining awareness of the importance of semantics in ESA
interoperability, and some small but active vendors, such as Semagix, are starting to introduce
ontologies and semantic language support to cover in particular the data mapping and transformation
processes for the data harmonisation. The main vendors do not seem to support ontologies but in
some cases they use taxonomies or glossaries.
3.1.3
Ontology content
This section of the SoA is inherently different from the previous ones, since it is not technology
oriented but rather problem oriented. The previous sections described methods and tools aimed at
implementing ontologies for interoperability solutions, however, as anticipated, a semantics-based
solution requires a common understanding of the business context in which the cooperation takes
place. Such common understanding is represented by a reference ontology (RO). A RO contains the
specification of the relevant (for the community) concepts and relationships to be used during the
cooperation processes. The availability of ontology languages and tools represents an obvious
prerequisite, but no more. It is necessary that the community of reference commits to define the
ontology content and, using the available languages and tools, implements it in a machine readable
format.
A RO represents a given business domain, at a conceptual level. When starting to build a
business ontology, it is not necessary (better, not advisable) to start from scratch. In general (and in
the business domain in particular) there is a wealth of documents that represent, in different forms,
concepts of the domain to be modeled, such as standards, catalogues, glossaries, and also previous
developed ontologies. Among the rich variety of sources, in the SoA we focused on the following:
•
Some sources of term definitions like ISO and WordNet;
•
Enterprise Modelling Standards ISO 19439 and 19440;
•
RosettaNet, an XML-based business framework;
•
ebXML, UBL and Core Components;
•
The MIT Process Handbook;
•
The Supply-Chain Operations Reference (SCOR) Model.
This section highlights also the process of moving from a lexicon to a terminology to an ontology,
by shifting the focus from a linguistic representation to the conceptual one.
Conclusion and gap analysis – The process of conceptualisation of a given domain is per se a
complex, time consuming, task. For example, it took over two years to develop The Global Invoice
Message (AIAG E-14), a global UN/EDIFACT message set for the automotive industry.1 Similarly, the
recently released Universal Business Language (UBL) 1.0, which defines XML versions of the
documents required for a typical order-to-invoice procurement cycle, “…represents six years of
development in building a standard XML business syntax”. For this reasons, seen also the limited
resources available in Athena for the semantic interoperability solutions, the choice was to limit the
effort in building domain ontologies in the project and to use as much as possible existing resources. In
particular, the program for the next period is:
•
to focus on specific trial ontologies to prove the feasibility of the proposed solution;
•
to make the best use of existing sources of concept definitions, leveraging on the existing
material;
1
information from http://www.gefeg.com/en/service/files/global_invoic_e14.pdf
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page 6 / 244
P- Project
ATHENA Project
Document
•
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
to identify one or two preferred pilot scenarios where the ontology-based solutions will be
experimented and demonstrated;
capitalise on the experience and define a number of guidelines, to trace the path for a more
extensive use of ontology-based solutions;
identify criteria to select where it is advantageous to use semantic solutions and where the effort
of building and maintaining one (or more) ontology would not pay back (i.e., where traditional
choices would be advisable).
•
•
3.1.4
Relationship between the Interop and the Athena SoA
As part of the survey activity required by the SoA report, we devoted special attention to the SoA
on ontologies produced by Interop, which some important material has been derived. However, even if
the topic is the same, there is a main difference between the two SoA. Essentially, such difference is
represented by the two underlying perspectives.
In fact, Interop has a more research oriented perspective, while in Athena the SoA has been
achieved having in mind a more practical orientation. For instance, the most advanced ontology
languages, in Interop have been analytically presented, while in the Athena they have been illustrated
by using a more practical approach based on synoptic tables.
3.2 DA3.1-B Summary. Athos technical Specifications
The part B is divided into two subparts. The first consists in the representational specifications of Athos and the
second in the architectural and implementation features.
3.2.1
The representational specifications of Athos
In building an Ontology Management Systems, such as Athos, the most relevant aspects is the
underlying ontology meta-model, that is the characteristics of the ontology modelling paradigm. Such a
paradigm determines the modelling capability of the system. In this respect, Athos is based on OPAL:
the Object, Process, Actor modeling Language. Today, one of the ontology languages that are gaining
a progressive consensus is OWL, the Ontology Web Language proposed by the W3C. On top of OWL,
the modelling method OPAL proposed a number of predefined concept categories that help the
ontology modeller in his/her task. The pre-defined categories of OPAL are associated with a number of
inherent integrity constraints. In fact, OPAL has been conceived having two main goals: to provide an
ontology building method capable of supporting and guiding the ontology modeller and to provide a
number of inherent constraints, associated to the above mentioned categories, used to guarantee a
better quality for the built ontology.
The concept categories of OPAL are organised in primary and complementary meta-concepts.
The primary meta-concepts are:
•
Object
•
Process
•
Actor
•
•
•
•
And complementary meta-concepts:
Attributes (atomic, complex)
Message
Business Document
Operation
There are additional meta-concepts, such as event and decision, that are not currently considered
for implementation. We will consider, after the first phase of experimentation, what to include in the
next release of Athso 2.0, due at month 20.
In the report, the formal specifications of OPAL 1.0 are provided, starting with an abstract syntax,,
represented with a concise algebraic method, followed by its formal semantics, expressed using OWL
DL.
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page 7 / 244
P- Project
ATHENA Project
Document
3.2.2
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
The functional and architectural specifications
The second subpart of this D.A3.1 Part B report presents the functional and architectural
specifications of Athos. In particular, the following modules are illustrated:
•
GUI Manager;
•
Client Manager;
•
Application Logic Module;
•
Database Access Manager.
Athos has been developed with two main architectural choices in mind:
Service Oriented Architecture: Athos is fully WebService-enabled, on two fronts. In fact it is ready
to interact with external services, by using a SOAP interface, and at the same time it exhibits an
interface as a WebService, and it is ready to publish its semantic services over the Internet.
Plug-in Enabled. The second major issue concerns the possibility for Athos to evolve in a smooth
way, having structured its internal architecture according to the Plug-in philosophy. In particular, having
carefully studied the two plug-in models of Eclipse and Protégé, we conceived a particular solution,
based on the definition of ZExtension Points (where Z stands for Zope) that implements e Plug-in
approach by optimally using the characteristics of the Zope Platform, on which Athos is based. The
report contains a section of instructions on how to develop new Athos plug-ins.
3.3
DA3.1-C Summary. The User Manual of Athos
The User Manual of Athos has an organisation that aims at presenting in the first sections the
modelling philosophy of OPAL, which is at the base of the implementation choices and the user
interface of the system.
The main characteristics of the Athos system, that are reflected in the User Manual, are:
•
The modelling capabilities, based on OPAL, that are implemented in the GUI. To this end, the
OPAL representation method has been organised into a number of templates, that guides the
user in his/her modelling activities. A template is organised in three sections:
o Identification Section, that allows all the meta-data of the concept (name, author, XML tag, etc.)
to be introduced;
o Structural Section, that provides the constructors of OWL-DL, so that the user can define the
structural view of the concept (e.g., properties, hierarchies, constraints, etc.)
o “Kind” Specific Section. While the two previous sections are the same for all the meta-concepts
(referred to as kind in OPAL), this section is different for each kind, and contains a number of
properties and relationships that are meaningful to be defined in a business domain (this is the
key part that makes OPAL a business oriented ontology modelling method).
•
The usage modes. Two are the usage modes of Athos:
o Glossary mode: it allows for a simplified use of the tool. This modality is interesting for the
applications that don’t need a full fledged ontology or in the preliminary stages of the production
of a complex domain ontology;
o Ontology mode: this modality allows all the functions of Athos to be used, in order to build,
verify, inspect, and more in general manage a complex domain ontology.
•
The User Profiles. In Athos there are three user profiles that can be activated. The profiles are
described in ascending order, with respect to their privileges. It means that a profile with a higher
ranking inherits the privileges of the lower profiles. The profiles are:
o Ontology User: it allows any user, even with a limited ontology culture, to access the ontology
and inspect its content;
o Ontology Master: this profile is assigned for a specific ontology. It allows the user to access all
the functions that pertain to that ontology;
o Athos Admin: this is the higher profile, that allows the Admin to activate a new ontology, remove
an existing ontology, manage the users, etc.
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page 8 / 244
P- Project
ATHENA Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1
IP- Project - No
ATHENA - Project Number
Date
507849
04.04.05
The Athos system presents a rich set of functionalities, that can be activated through the GUI. As
anticipated, not all the functions are available to all the profiles. Below a list of function categories is
reported, as seen by the Ontology Master (the Ontology User does not see functions that allow the
ontology content to be altered):
•
Defining concepts
•
Updating a concept
•
Deleting a concept
•
Viewing a concept
•
Viewing the ontology, in different forms:
o Alphabetic view
o Kind specific view
o Specialization hierarchy view
o Decomposition hierarchy view
•
Import/export of an ontology, or part of it.
•
Reporting
3.4
Conclusions
For what concerns the conclusions of this deliverable, we already reported, in each of the three
parts that compose the document, the key issues that emerged from our study. Here we wish to state
again a few key outcomes:
•
Analysing the most relevant ontology representation languages, we identified the need for an
ontology modelling method specifically characteristic for the business domain. Domain specificity
represents the capacity of a language to model in a more intuitive and effective way a given
domain ontology, in our case the business domain. This is why in Athena we propose to use
OPAL, which is the ontology modelling method based on OWL and enriched with specific
constructs pertaining to the business domain.
•
Based on OPAL we implemented Athos, the Athena Ontology management System. Athos is a
web application. We designed it with a plugin architecture, inspired to the Eclipse and Protégé
plug-in model, in order to ease the extension of functionalities. Furthermore Athos is web service
enabled on two fronts. It can interact with external services, by using SOAP interfaces, and at the
same time it exhibits its functionalities as a WebService.
050404_ATHENA_DA31_Summary_v10.doc
CONFIDENTIAL
Page 9 / 244
Programme
Integrating and Strengthening the European Research
Strategic Objective
Networked businesses and governments
Integrated Project / Programme Title
Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks
and their Application
Acronym
ATHENA
Project No
507849
ATHENA – Project Name
Knowledge Support and Semantic Mediation Solutions
ATHEN A - Project No
A3
DELIVERABLE D.A3.1
Title
SoA on Ontologies and the Ontology Authoring
and Management System, with Ontology
Modelling Language.
Part A: State of the Art on Ontologies
Leading Partner: CNR-IASI
Security Classification: Project Participants (PP)
March 31st, 2005
Version 1.1
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Versioning and contribution history
Version
0.1
Description
First draft – Contribution from LEKS, FORMULA an SAP
Comments
A3 Revision from IPK (FW Jaekel) and TXT (E Coscia)
0.2
Second draft – Updates from LEKS, Formula and SAP taking into account
suggestions from the internal reviewers
0.3
Added other contribution from FORMULA and LEKS
1.0
Added executive summary
1.1
Relationships with Interop Soa added
Deliverable process schedule
No
1
2
3
4
5
Process step
Responsible
Initial drafting of the deliverable
including structure, comments and first F. Taglino (CNR)
basic content to be sent to to-beM.Missikoff (CNR)
contributors.
F.Taglino (CNR)
First round of contributions. Work
package member and others to
D. Gazzotti
contribute first iteration to owner of
(Formula)
the deliverable
S-M Thomas (SAP)
Owner to consolidate first round input
F. Taglino (CNR)
and distribute to contributors
F.Taglino (CNR)
L. Pondrelli
Final round of contributions including
(Formula)
comments form peers/AL to be sent to
S-M Thomas (SAP)
owner
E. Coscia (TXT)
F.W. Jaekel (IPK)
F. Taglino (CNR)
Final consolidation of input and
finalisation of “technical” document to
M. Missikoff (CNR)
be send to
G. Callegari (CNR)
Timing
05.07.2004
27.08.2004
22.10.2004
14.01.2005
28.01.2005
6
Quality check – e.g. Peer Review
Elmar Dorner (SAP)
14.03.2005
7
Final editing
26.07.2005
8
Final Approval from partners or
delegates to be send to Programme
Office
9
Submission to Commission
Programme office
PCC members or
delegates: Guy
Dougmeings (itrec)
Joerg Muller
(Siemens)
Programme
Committee
050404_ATHENA_DA31_PartA_V10.doc/derek
Comments
Only part B has been revised. We
didn’t receive any feedback for Part A
and B.
21.03.2005
31.03.2005
CONFIDENTIAL
Page 11 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Table of contents detailed
1
Summary
16
1.1
Ontology modelling languages
16
1.2
Ontology related software systems
17
1.3
Ontology content
19
1.4
Relationship between the Interop and the Athena SoA
19
1.5
Rationale of the document organization
20
2
Ontology methods and languages
22
2.1
Objectives
22
2.2
Framework for languages description
22
2.3
Diagrammatic notations
2.3.1
Conceptual graphs
2.3.2
Semantic networks
2.3.3
UML (Unified Modeling Language) (detailed form)
2.3.4
Topic Maps
2.3.5
Concept Maps
23
24
24
25
26
27
2.4
Logic-oriented
2.4.1
KIF (Knowledge Interchange Format)
2.4.2
Cycl
2.4.3
SCL (Simple Common Logic - CL working group)
2.4.4
LP/Prolog
2.4.5
SWRL
2.4.6
F-Logic (M. Kifer, G. Lausen, J. Wu)
2.4.7
Description Logics (a family of languages)
27
28
28
29
29
30
30
31
2.5
Frames-oriented
2.5.1
Frame Systems
2.5.2
OKBC
2.5.3
XOL
2.5.4
SHOE
2.5.5
Ontolingua
2.5.6
OCML
2.5.7
OIL (Ontology Inference Layer)
32
33
33
34
34
35
36
37
2.6
Web-oriented
2.6.1
XML Schema (W3C consortium)
2.6.2
DAML+OIL
2.6.3
RDF(S)
2.6.4
OWL (Ontology Web Language) Æ scheda
37
37
38
38
39
2.7
Process specification languages
2.7.1
Process algebras
2.7.2
Pi-Calculus
2.7.3
PSL (Process Specification Language)
2.7.4
Petri Nets
2.7.5
OWLS-S
2.7.6
BPEL
40
41
41
41
45
45
46
2.8
A detailed description of some languages
47
2.9
Conclusions
73
2.10
References
73
3
Ontology management system comparison
82
3.1
Ontology interoperability and standards
82
3.2
Survey criteria
83
3.3
Surveyed tools
84
050404_ATHENA_DA31_PartA_V10.doc/derek
CONFIDENTIAL
Page 12 / 244
IP- Project
ATHENA -Project
Document
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
KAON
Ontolingua (with Chimaera)
OilEd
Protégé 2000
pOWL
507849
04.04.05
84
84
85
86
87
3.4
Survey results
88
3.5
Conclusion
91
4
Inference engines comparison
92
4.1
Survey criteria
92
4.2
Survey results
93
4.3
Conclusion
94
5
Other tools and methodologies not considered in the surveys
95
5.1
IBM Ontology Framework
5.1.1
IBM Integrated Ontology Development Toolkit
5.1.2
IBM Ontology Management System (SNOBASE)
5.1.3
IBM Ontology-based Web Services for Business Integration
96
96
96
97
5.2
97
6
6.1
KPONTOLOGY
EAI solutions (Enterprise Application Integration)
98
EAI in the semantic context
98
6.2
EAI solutions
6.2.1
IBM - Web Sphere Business Integration [25]
6.2.2
Microsoft – BizTalk [26]
6.2.3
TIBCO – ActiveEnterprise [29]
webMethods - Integration Platform
6.2.4
SeeBeyond – Integrated Composite Application Network (iCAN) [28]
6.2.5
BEA WebLogic [30]
6.2.6
SAP Netweaver [35]
99
99
99
100
101
101
102
103
6.3
Survey criteria
103
6.4
Survey results
104
6.5
The EAI products with ontology tools
106
6.6
Conclusion
106
6.7
References
107
7
Ontology contents
110
7.1
Terminology Management and Ontologies
110
7.2
Overview of types of existing standards and initiatives related to collaborative business
114
7.3
Database of B2B documents - GEFEG
7.3.1
Overview of GEFEG – copied from their web site:
115
116
7.4
ISO Standards as a source of terminology
7.4.1
ISO Standards related to terminology management
7.4.2
Short Description of ISO
116
117
117
7.5
Enterprise Modelling: ISO 19439 and ISO 19440 Standards
117
7.6
WordNet as a source of terms and taxonomy
118
7.7
RosettaNet
119
7.8
ebXML
120
7.9
Universal Business Language (UBL)
120
7.10 Core Components – part of the ebXML Framework
7.10.1
Explanation of Core Components
7.10.2
Core Component Types
050404_ATHENA_DA31_PartA_V10.doc/derek
CONFIDENTIAL
121
122
123
Page 13 / 244
IP- Project
ATHENA -Project
Document
7.10.3
7.10.4
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
Business Information Entities
Summary table for CCTS
507849
04.04.05
123
124
7.11 Context
7.11.1
Processes associated with core components
124
126
7.12
126
MIT Process Handbook
7.13 SCOR
7.13.1
SCOR – source of information
7.13.2
SCOR summary
7.13.3
Overview of SCOR
7.13.4
SCOR and collaboration
7.13.5
SCOR Level 1
7.13.6
SCOR Level 2
7.13.7
SCOR Level 3
7.13.8
List of SCOR Process Elements from SCOR 5.0 (Level 3)
7.13.9
SCOR Project
7.13.10
Metrics
7.13.11
Tools
7.13.12
Relation to other vocabularies
7.13.13
Potential significance of SCOR for Athena
7.13.14
Other second-generation reference-models
127
127
127
128
130
130
130
132
133
133
134
134
134
134
135
7.14
Conclusions
135
7.15
References
135
050404_ATHENA_DA31_PartA_V10.doc/derek
CONFIDENTIAL
Page 14 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Figures
Figure 1. ..... Resource management in the topic maps model. ............................................................ 26
Figure 2. ..... Primitive Lexicon of PSL................................................................................................... 44
Figure 3. ..... The top level of the Service ontology................................................................................ 46
Figure 4. ..... KAON Workbench............................................................................................................. 84
Figure 5. ..... Ontolingua web page ........................................................................................................ 85
Figure 6. ..... OilED................................................................................................................................. 85
Figure 7. ..... Protégé 2000 .................................................................................................................... 86
Figure 8. ..... pOWL................................................................................................................................ 87
Figure 9. ..... EAI market ........................................................................................................................ 98
Figure 10. ... Types of Ontologies ........................................................................................................ 113
Figure 11. ... UML class diagram of components ................................................................................ 122
Figure 12. ... Names of core components............................................................................................ 122
Figure 13. ... Names of business information entities .......................................................................... 124
Figure 14. ... SCOR Hierarchical Model............................................................................................... 129
Figure 15. ... Level 2 of SCOR ............................................................................................................. 130
Figure 16. ... Example Thread Diagram............................................................................................... 131
Figure 17. ... SCOR Level 3 ................................................................................................................. 132
Figure 18. ... Performance Attributes and Metrics ............................................................................... 134
050404_ATHENA_DA31_PartA_V10.doc/derek
CONFIDENTIAL
Page 15 / 244
IP- Project
ATHENA -Project
Document
1
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Summary
A document on the State of the Art has a primary goal of acquiring a clear and up to date
understanding of the recent achievements in a given sector. In particular, in our case, we needed to
investigate on what is available in terms of current, most advanced ontology-based solutions.
Furthermore, in the Athena IP, we also intended to use the SoA on ontologies to understand to what
extent existing achievements can be used for our purposes and where we have to develop original, ad
hoc, solutions.
The SoA document is organised into three sections, to address in a clear and distinct way the
fundamental issues concerning ontologies in the perspective of the Athena IP: (1) Ontology modelling
languages, (2) Ontology management systems, Inference engines, EAI platforms, (3) Ontology
content. Please note that we addressed also EAI platforms since they are direct competitors of the
ontology-based services we intend to develop for interoperability and, recently, they are starting to
enrich their functionalities with semantic capabilities.
1.1
Ontology modelling languages
This section reports a survey of the most relevant languages used to model ontologies. The
section starts with the identification of the main criteria that allow each analysed language to be quickly
characterised. The languages have been organised into families, to group them on the basis of their
most prominent characteristics. We have identified the following families of languages:
•
Diagrammatic languages
•
Frame-oriented languages
•
Logic-based languages
•
Web-oriented languages
•
Process-oriented languages
During the work on the SoA numerous issues were raised. One concerns the possibility of
considering, in the SoA, only ontology languages usually accepted by the ontology community, or to
broaden the survey to other modelling languages, developed in other contexts, where conceptual
modelling is necessary (from Software Engineering to database design, from BP modelling to
Enterprise Engineering). In the literature there is not a clear separation of ontology languages from
other conceptual modelling languages. The ontology research field is still in its infancy and requires to
be consolidated. Some times, the debate addresses the problem of identifying what can be properly
considered as an ontology with respect to other repositories of abstract models, such as: a thesaurus,
a glossary, a data dictionary, a knowledge base. However, in order to restrict our analysis, adopting
the position that privileges for an ontology language a formal basis, and some reasoning techniques
associated to it. (But in the SoA, some relevant languages have been included that do not meet this
requirement.)
As anticipated, the ontology languages have been analysed using a set of predefined criteria,
concerning the basic constructs to define: concepts, attributes, relations, instances, formal properties
of attributes and relations, possible restrictions (e.g., on domain/range, on multiplicity) over them.
Conclusions and gap analysis - In the field of ontology languages there is an important debate
about the expressiveness of a language and the computational complexity exhibited by the related
services (essentially, the inference methods). Currently, the proposal that is gaining momentum is the
Ontology Web Language OWL, proposed by W3C. Such a language has a strong rooting in the formal
work achieved in Description Logics and, therefore, has a limited expressive power but the possibility
of developing effective (and complete) reasoning engines.
In the work of the A3 Project, we decided to adhere to the OWL proposal, but introducing some
enhancements due to its lack of domain specificity for the business domain.
In terms of requirements for Athena, there are three major features that we need to find in an
ontology modelling language:
•
formal basis, and availability of inference engines capable of reasoning over ontology content;
•
business-oriented constructs, to facilitate the construction of business ontologies (business
domain specificity)
•
expressive power, sufficient to model some characteristics related to process ontologies (e.g.,
precedence relation, conditionals to represent pre- and post-conditions).
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 16 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
None of the analysed languages presents at the same time the three above features. For this
reason, to fill this gap, we propose in Athena to use OPAL (Object, Process, Actor modelling
Language), which is the ontology modelling method based on OWL and enriched with specific
constructs. This issue is more widely elaborated in the document D.A3.1-B. There, a more extensive
list of requirements are presented, and some specifications of the proposed solutions are outlined.
1.2
Ontology related software systems
In this section we analyse the main software systems aimed at the development of ontologies and
at reasoning over them. Here we also address the current leading technology for interoperability: EAI,
mentioning their evolution towards semantic services.
Ontology management systems
This section surveys the most relevant OMS available on the market. Those are essentially
experimental solutions, mainly developed by academic groups. The most relevant OMS have been
analysed, by using a common set of criteria. Such criteria consider several important elements, such
as: the language used to model ontologies, the possibility of representing instances, the query
facilities, the web-orientation. A detailed list and explanation of the criteria used for the analysis can be
found at the beginning of Section 2 of this document.
The analysis started with a broad number of OMS, that was rapidly reduced to the most relevant
subset, in the perspective of the Athena IP. Such list includes:
•
KAON
•
Protégé
•
pOWL
•
Ontolingua (with Chimera)
•
OilEd
Conclusions and gap analysis. The requirements for the OMS of Athena have two main aspects,
one is its ontology representation method and the other is the key architectural features. For the
representation method we wanted to meet the domain specificity already introduced in the Section on
Ontology modelling languages (see OPAL issue). For what concerns the architectural features, the
main requirements, besides the most common ones (such as graphical user interface, import/export,
query facilities, instance handling) were: web application, with an extensive shared and distributed
usage possibility; log facility, to keep under control the activities of each user; possibility of integration
with a Glossary, for a more versatile, easy use of the terminological component of an ontology, web
service enabled, with a double role: to invoke web services and to publish ontology management
functions as a web service.
The reported analysis shows that the system that is getting closer to our requirements is pOWL.
However, there are a number of requirements for which pOWL does not show the needed
functionalities (please see the table of Sect 3.4). For these reasons we decided to develop Athos
(Athena Ontology System). Furthermore, Athos represents the most up to date version of a number of
ontology managers developed at LEKS in the last decade, capitalising therefore the experience and
the know-how acquired in previous important projects.
Inference engines
Reasoning facilities are a key element of a semantics-based solution. One of the main motivations
for using formal ontologies is the possibility of reasoning over the stored conceptual expressions. In
particular, in Athena, reasoning will be used for two major purposes: (i) consistency checking, to verify
that the ontology (and the semantic annotations, addressed in the second phase of the project) is free
of contradictions; (ii) rule-based productive reasoning, to achieve runtime interoperability when two or
more (heterogeneous) enterprise software applications need to cooperate. The latter is achieved by
means of a set of reconciliation rules that allow different messages to be transformed.
•
•
•
•
•
In the survey, five of the most relevant inference engines have been analysed:
Jess
Jena2
Racer
Metalog
SWAP/CWM
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 17 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Conclusions and gap analysis. The analysis of the State of the Art revealed the high complexity of
an artefact like an inference engine and the high level of specialization exhibited by the groups working
on this matter. These elements, joined to the existence of a large community that produced good
results in the last period (and the limited resources available to this end in the Athena project),
convinced us of the opportunity not to develop a new reasoner, but to acquire and adapt one (or more)
existing engine. The survey revealed that the existing engines are somehow specialised either towards
“truth maintenance” (i.e., consistency checking) or towards production reasoning. In the first category
the most relevant appears to be Racer [133], while for the second Jena2. This problem is widely
known in the community and, for this reason, the team of Jena2 developed an adapter (based on a
specific interchange format, named DIG) to create a tight cooperation with Racer. As a conclusion, we
decided to investigate more extensively on the possibility of jointly using Racer and Jena2 for
consistency checking and runtime reconciliation, respectively. For the latter objective, a comparison
analysis will be performed to contrast the performances of Jena2, based on RDF-like rules, against
solution based on rules modelled by using XSLT.
Enterprise Application Integration (EAI) platforms
In this State of the Art we decided to include the analysis of the most advanced, among the
industrial-strength, current technology solutions conceived to solve interoperability problems among
enterprise software applications: Enterprise Application Integration platforms. Current EAI
implementations do not make use of ontology-based solutions, nevertheless they represent in many
situations a valuable approach to solve interoperability problems. In the perspective of a better
understanding of pros and cons of EAI, and to contrast such a technology with semantics-based
solutions, we decided to include this part in the SoA.
As emerges from the study, today there are many competitors in the EAI market, and it is even
difficult to draw a precise boundary to identify them from other products, such as workflow or
cooperation platforms, that provide some functionalities to support interoperability solutions. Within
such a rich context, we decided to focus on the market leaders (according to Gartner Group), that also
present the richer set of functionalities.
•
IBM WebSphere Business Integration
•
MS BizTalk
•
TIBCO
•
WebMethods
•
SeeBeyond
•
SEA WebLogic
•
SAP Netweaver
Conclusions and gap analysis – EAI platforms represent an important technological advancement,
with respect to the past “ad hoc” approach to enterprise software application (ESA) interoperability. In
fact, while an “ad hoc” solution requires the development of an adaptor (essentially a piece of
software) for each pair of applications needing to communicate, an EAI solution is based on a central
hub (or software bus) capable of interconnecting the different ESAs with a centralised set of adapters.
Furthermore, the logics of the adapters, for the runtime reconciliation of messages, is expressed with a
rule language, instead of being coded in a programming language. However, the basic philosophy
requires that the reconciliation logics is implemented for each pair of communicating applications,
leading to the geometrical explosion of the number of adapters to be implemented.
The semantic interoperability approach intends primarily to reduce the problem of the geometrical
growth of the adapters, creating a common understanding of the business scenario (by means of a
reference ontology) and unifying the reconciliation adapters to such a common scenario. We believe
that semantic interoperability is not the panacea that will solve all possible interoperability problems in
all possible situations. We believe that it will contribute to solve a good number of problems, but there
will be still a number of cases where good “traditional” technology will perform well, or even better.
Since the construction of a common business scenario does not come without a cost, we believe that
there are cases where more traditional solutions (EAI, but even “ad hoc” for simple cases) will be a
better choice, even in presence of a successful semantic interoperability solution.
Finally, the EAI sector is gaining awareness of the importance of semantics in ESA
interoperability, and some small but active vendors, such as Semagix [142], are starting to introduce
ontologies and semantic language support to cover in particular the data mapping and transformation
processes for the data harmonisation. The main vendors do not seem to support ontologies but in
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 18 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
some cases they use taxonomies or glossaries.
1.3
Ontology content
This section of the SoA is inherently different from the previous ones, since it is not technology
oriented but rather problem oriented. The previous sections described methods and tools aimed at
implementing ontologies for interoperability solutions, however, as anticipated, a semantics-based
solution requires a common understanding of the business context in which the cooperation takes
place. Such common understanding is represented by a reference ontology (RO). A RO contains the
specification of the relevant (for the community) concepts and relationships to be used during the
cooperation processes. The availability of ontology languages and tools represents an obvious
prerequisite, but no more. It is necessary that the community of reference commits to define the
ontology content and, using the available languages and tools, implements it in a machine readable
format.
A RO represents a given business domain, at a conceptual level. When starting to build a
business ontology, it is not necessary (better, not advisable) to start from scratch. In general (and in
the business domain in particular) there is a wealth of documents that represent, in different forms,
concepts of the domain to be modeled, such as standards, catalogues, glossaries, and also previous
developed ontologies. Among the rich variety of sources, in the SoA we focused on the following:
•
Some sources of term definitions like ISO and WordNet;
•
Enterprise Modelling Standards ISO 19439 and 19440;
•
RosettaNet, an XML-based business framework;
•
ebXML, UBL and Core Components;
•
The MIT Process Handbook;
•
The Supply-Chain Operations Reference (SCOR) Model.
This section highlights also the process of moving from a lexicon to a terminology to an ontology,
by shifting the focus from a linguistic representation to the conceptual one.
Conclusion and gap analysis – The process of conceptualisation of a given domain is per se a
complex, time consuming, task. For example, it took over two years to develop The Global Invoice
Message (AIAG E-14), a global UN/EDIFACT message set for the automotive industry.1 Similarly, the
recently released Universal Business Language (UBL) 1.0, which defines XML versions of the
documents required for a typical order-to-invoice procurement cycle, “…represents six years of
development in building a standard XML business syntax”. For this reasons, seen also the limited
resources available in Athena for the semantic interoperability solutions, the choice was to limit the
effort in building domain ontologies in the project and to use as much as possible existing resources. In
particular, the program for the next period is:
•
to focus on specific trial ontologies to prove the feasibility of the proposed solution;
•
to make the best use of existing sources of concept definitions, leveraging on the existing
material;
•
to identify one or two preferred pilot scenarios where the ontology-based solutions will be
experimented and demonstrated;
•
capitalise on the experience and define a number of guidelines, to trace the path for a more
extensive use of ontology-based solutions; identify criteria to select where it is advantageous to
use semantic solutions and where the effort of building and maintaining one (or more) ontology
would not pay back (i.e., where traditional choices would be advisable).
1.4
Relationship between the Interop and the Athena SoA
As part of the survey activity required by the SoA report, we devoted special attention to the SoA
on ontologies produced by Interop, which some important material has been derived. However, even if
the topic is the same, there is a main difference between the two SoA. Essentially, such difference is
represented by the two underlying perspectives.
In fact, Interop has a more research oriented perspective, while in Athena the SoA has been
achieved having in mind a more practical orientation. For instance, the most advanced ontology
languages, in Interop have been analytically presented, while in the Athena they have been illustrated
by using a more practical approach based on synoptic tables.
1
information from http://www.gefeg.com/en/service/files/global_invoic_e14.pdf
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 19 / 244
IP- Project
ATHENA -Project
Document
1.5
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Rationale of the document organization
Ontologies and their applications are the main objectives of the A3 project. This State of the Art
aims at giving an overview of what exists in terms of ontology description languages, tools for
managing ontologies and possible resources for ontology building. For this reason, the SoA has been
organized in the following three sections:
•
Section I: Ontology methods and languages, led by LEKS, CNR-IASI-CNR
•
Section II: Ontology management and reasoning tools, led by Gruppo Formula
•
Section III: Ontology contents, led by SAP
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 20 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Section I
Ontology methods and languages
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 21 / 244
IP- Project
ATHENA -Project
Document
2
2.1
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Ontology methods and languages
Objectives
This section is aimed at identifying and analyzing the main characteristics of existing ontology
specification languages and contrast the identified characteristics with the Representational Semantic
needs of the Athena Project.
This State of the Art (SoA) will be a basis to define the key representation specifications of Athos
(Athena Ontology management System) for ontology modeling with the aim of applying ontologybased solution to enterprise application interoperability.
The analysis of this State of the Art relies on the already consolidated States of the Art built by
previous European Projects (e.g., IDEAS, OntoWeb, OnToKnowledge) resources, namely books,
scientific publications, language specifications and white papers. Another important contribution has
come from the synergies between the Athena project and the INTEROP project[66]. In particular the
collaboration has been mainly established with the INTEROP WP8, “Ontology-based integration of
Enterprise Modelling and Architecture & Platforms”.
Since our work is focused on the analysis of the existing proposals in the field of the business
knowledge representation, we decided to include in our review some process specification languages,
with the aim of identifying the ontological notions provided by these languages and evaluate the
possibility of including them in the language used in Athena to represent the Business domain
knowledge.
According to the collected material, more than 30 languages, among ontology-specification and
process-specification languages, have been identified. An evaluation framework for the analysis of
these languages has been defined and some of the addressed languages have been described
according to this framework.
2.2
Framework for languages description
According to the proposed Framework, the description of the ontology/process specification
languages is structured in two sections: a first section, containing an overview of the existing
languages, and a second section, containing a detailed description of a selected subset of them.
1)
2)
3)
4)
5)
Five categories of specification languages have been identified. They are:
Diagrammatic notations
Logic-oriented
Frames-oriented
Web-oriented
Process specification-oriented
The specification languages are classified in these categories taking into account their underlying
KR paradigm. It is important to note that the same language may present characteristics proper of
several categories; for this reason we present a table indicating, for each language, which
category(/ies) it belongs to (see Table 1). In particular, for each language, a “x” in bold indicates the
category it has been inserted into, while a simple “x” indicates another category it belongs to.
Furthermore, a brief description of each language is given, in order to emphasize their main
characteristics.
In the “Detailed Description”, Section 2.8, a selection of the most representative specification
languages is taken into consideration and they are analyzed in a more detailed way. For the structure
of this Section we refer to the CommonKADS Framework [134] and to the evaluation of languages
presented in the Ontological Engineering book[46].
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 22 / 244
IP- Project
ATHENA -Project
Document
Diagrammatic
notations
Conceptual
graphs
Semantic
networks
UML
Topic Maps
Concept Maps
KIF
CycL
Prolog
SWRL
F-Logic
Non-Mon,
modalities,
temporal logics
Description
Logics
Frame
Systems
OKBC
XOL
SHOE
OIL
Ontolingua
OCML
XML Schema
RDF(S)
DAML+OIL
OWL
PIF
PSL
Process
Algebras
Pi Calculus,
ADT (B
Calculus)
OWL-S
WSMF
Petri Nets
BPEL
Table 1.
2.3
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
LANGUAGES GRID
LogicFramesoriented
oriented
x
Web-oriented
507849
04.04.05
Process
specificationoriented
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Languages categorization
Diagrammatic notations
The characterizing feature of languages belonging to this category is a diagrammatic approach to
knowledge representation. This class of languages, usually, represents concepts as (labeled) nodes of
a graph (/net). For what concerns the relations, they are represented either as arcs of the graph or by
using nodes, as well as concepts, but with a different shape.
The languages which are mainly characterized by a diagrammatic notation, and that will be
considered in this work are:
•
Conceptual graphs
•
Semantic networks
•
UML (OMG submission for ontology representation)
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 23 / 244
IP- Project
ATHENA -Project
Document
•
•
2.3.1
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Topic Maps
Concept Maps
Conceptual graphs
Conceptual Graphs (CG) are a special kind of semantic network. They were introduced by John F.
Sowa [115] and are based on earlier studies on Existential Graphs by Peirce [135].
Basically, a conceptual graph is a bipartite graph containing two kinds of nodes, called
respectively concepts and conceptual relations. Arcs link concepts to conceptual relations, and each
arc is said to belong to a conceptual relation. There are no arcs that link concepts to concepts or
relations to relations. Concepts have an associated type and a referent. A referent is a way to denote
the entity of the Universe of Discourse which the concept refers to. It consists of a quantifier, a
designator, which either “points” to the referent or describes it, and a descriptor, which is a Conceptual
Graph describing some aspects of the referent. Note that a quantifier here may only be of existential
kind or specify that a precise number of instances of the referent exists. A descriptor is considered as
a Conceptual Graph nested into a concept. The concept is said to be a Context for the nested CG.
Conceptual relations are typed, too. A relation type associates to a conceptual relation a valence
(equal to the number of arcs that belong to the relation) and a signature that constraint the types of
concepts linked to the relation. Some basic notions on Conceptual Graphs may be found in [23].
Conceptual Graphs first aim was to model concepts and their relations in a way that is both close
to human language and formal, in order to provide a readable, but formal design and specification
language. They should also allow a form of reasoning that may be performed directly on their Graphic
representation, by means of subsequent transformations applied to the (conceptual) Graph.
The book published by Sowa received conflicting initial reactions[24][114]. Subsequent papers
clearly shown some errors in Sowa’s theses, and highlighted the need for a much cleaner formalization
of CGs [125]. Various other attempts at formalizing CGs have been proposed during the years.
Another problem related to Conceptual Graphs was that, since they have shown to have the same
expressive power of first order logic, most of the problems that are interesting when reasoning on
conceptual graphs (like validity and subsumption) are undecidable. Several problems remain NPcomplete even when reasoning on restricted versions of the Graphs, like Simple Graphs
(corresponding to the conjunctive, positive and existential fragment of FOL). To overcome this
inconvenient, there have been attempts to identify guarded fragments of CGs[6].
Sowa is preparing a proposal for a standardization of Conceptual Graphs, to be submitted to
ISO[25]. The draft presents conceptual graphs as a graphic representation for logic, with the full
expressive power of first-order logic and with extensions to support meta-language, modules, and
namespaces. It describes the abstract syntax on which conceptual graphs are based and also three
concrete syntaxes that may be use for actual representation of Conceptual graphs. They are,
respectively, a Display Form, which is essentially graphical, a linear form, which is textual, and a
machine-readable form, called CGIF (Conceptual Graphs Interchange Format). The draft asserts that
CGIF sentences may be converted to logically equivalent sentences in the KIF language, (cf. Section
2.4.1). This allows to give CGIF sentences the same model theoretic semantics defined for the KIF
language.
The draft also gives a deductive system for Conceptual Graphs based on six “canonical formation
rules”. Each rule performs one basic graph operation. Logically, each rule has one of three possible
effects: it makes a CG more specialized, it makes a CG more generalized, or it changes the shape of a
CG while leaving it logically equivalent to the original. All the rules come in pairs: for each
specialization rule, there is a corresponding generalization rule; and for each equivalence rule, there is
another equivalence rule that transforms a CG to its original shape. These rules are essentially
graphic. Each rule is said to have a correspondent inference rule in predicate calculus. These
inference rules, however, are not currently shown in the draft.
2.3.2
Semantic networks
Semantic networks are a graph based knowledge representation model. The nodes of a Semantic
Network represent concepts or objects and the links represent relations between these items. Links
are usually directed and labeled.
Use of semantic networks to represent association between concepts was first introduced by
psychologists[105] to model the organization of human memory, with particular regard to how word
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 24 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
concepts are memorized. The basic assumption was that the “meaning” of a word could be
represented by the set of its verbal associations. From this perspective, concepts have no meaning in
isolation, and only exhibit meaning when viewed relative to the other concepts to which they are
connected by relational arcs. Later, other features were added to the networks model. In particular,
some links with special meaning like ISA associations were considered. This allowed to view networks
as taxonomies of concepts.
As semantic networks seemed to mimic the way the human mind structures knowledge, they
almost immediately captured the attention of the AI and Knowledge Representation research
communities. They have been used for knowledge representation Systems and extensively studied.
Despite this big influence, a major problem with semantic networks was a lack of clear semantics of
the various network representations. In particular, they lacked a clear meaning for what nodes and
arcs represented. Semantic networks do tend to rely upon the procedures that manipulate them. No
fundamental distinction is made between different types of links, for example those that describe
properties of objects, and those that make assertions, nor between classes of objects and individuals.
The interpretation of nodes suffers an analogous ambiguity. One interpretation of generic nodes (ones
that refer to a general class or concept) is as sets. Thus the relation holding between a node at one
level of a hierarchy and that at a higher level is that of subset to superset. If the generic node is
interpreted as a set, then the relation of nodes representing individuals to generic nodes in the network
is that of set membership. A second interpretation of generic nodes is as prototypes, and of instance
nodes as individuals for whom the generic nodes provide a prototypic description. Individuals will then
be more or less like the prototype.
Several studies tried to give more precise semantics to networks (e.g. [126][13][1][14]). The
research trend originating from these first attempts has lead to the development of Description Logics.
2.3.3
UML (Unified Modeling Language) (detailed form)
UML[122] is a graphical modeling language that provides a syntax to model information systems
in an object-oriented fashion.
Over the years, its use has been extended to a variety of different aims, including the design of
databases schemas, XML document schemas, knowledge models. It can be used also for business
modelling and modelling of other non-software systems.
•
•
•
UML constructs may be roughly divided into three categories:
diagrams that represent static application structure;
diagrams that represent aspects of dynamic behaviour and constructs
diagram that represent constructs for organizing the various parts of the models and managing
interactions and dependencies between them.
It also provides mechanisms and constructs that allow to extend the language itself.
Beside the main language specification, several extensions and complementary specifications
have been produced over the time. In particular, an XML based textual format, XML Metadata
Interchange (XMI)[129], and the OCL (Object Constraint Language) which allows to specify
constraints, the OMG MOF (Meta Object Facility)[89].
UML has been mainly designed for human-to-human communication. Its intended aim was to
provide a standardized graphical syntax to be used as a mean to specify, document and visualize
models of complex systems.
Its primary drawbacks come from this mainly graphical character -There is no standard textual
representation for UML constructs, though the OMG is in the process of adopting the XMI as a
standard for stream-based model interchange - and a lack of formally defined semantics.
Various attempts have been made to give formal semantics to the language (e.g. [35][24][34]). In
particular, latest proposals, such as[19], are based on Description Logics and try to establish a solid
basis for allowing automated reasoning techniques, to be applicable to UML class diagrams.
Concurrently, there have been various proposals that advocate the use of UML for ontology
modeling and representation. For example,[27] focuses on a subset of the language (In particular the
Class Diagram, complemented by the OCL language in order to express constraints and rules).
[9]examines similarities and differences between UML and ontology languages like DAML+OIL (cf.
Section 2.6.2), and [54] analyzes the problem of assigning ontologically well-founded semantics to the
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 25 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
UML modeling constructs.
2.3.4
Topic Maps
Topic Maps are a way of modelling a set of subjects, the relationships between them and
additional information about them, with the same logics of a “back-of-book” index.
The topic map paradigm is described in the ISO standard ISO 13250:2002[128]. The first edition
of the ISO specification (2000), described an interchange syntax (HyTM) based on SGML. Since then,
a separate consortium, TopicMaps.Org[121], have produced a version of the topic map paradigm for
use in a web environment. The XML Topic Maps (XTM) 1.0 specification[131] developed by
TopicMaps.Org defines an interchange syntax based on XML and XLink. XTM has now been adopted
by ISO and the ISO 13250 standard in its second edition now contains both syntaxes.
In essence a topic map can be thought of as consisting of just three things:
Topics which describe subjects in the real world. A subject may be something that is addressable
by a machine (e.g. a web-page with a URL), something which is not addressable (such as a person) or
even an abstract concept (such as 'Music').
Associations which describe the relationships between topics. The association construct may
include additional typing information which specifies the nature of the relationship between the topics
and also what role each topic plays in the relationship. So an association can be used to represent
such common concepts as a hierarchy, or a group but also more complex relationships such as a
meeting (with topics representing people and playing roles such as 'chairman', 'scribe' and 'attendee').
Occurrences which connect a topic to some information resource related to the topic. The
occurrence can be used to specify both the information resource (or the information itself) and the
nature of the relationship between the information resource and the topic. For example, a topic could
represent a person and that topic could have an occurrence which is a URL which points to the
'homepage' of the person.
Conceptual
Topic Relation
Conceptual
Association Relation
Conceptual
Occurrence
Relation
Conceptual
Resource
Relation
Figure 1.
Resource management in the topic maps model.
Furthermore, other important concepts are:
Topic classes, Occurrences classes, Association classes: allow to group different kinds of topics,
occurrences and associations, respectively. Topics, occurrences and associations are instances of
such classes. It is important to note that these classes are topics as well. It is possible to define a
taxonomic hierarchy of these classes.
Scope: a scope indicates the context within which a characteristic of a topic (a name, an
occurrence or a role played in an association) may be considered to be true. One common use of
scope is to provide localised names for topics. For example "company" in English could be "société" in
French or "Firma" in German. They all describe the same concept and so should be represented by
the same topic. Rather than creating separate topics one should instead create a single topic to
represent the concept of a company and add to it three separate base names, using scope to indicate
that a particular base name should be used for a specific language environment.
In addition to defining these basic structures, the topic map standards also define the way in which
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 26 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
two or more topic maps may be combined or merged. Topic map merging is a fundamental and highly
useful characteristic of topic maps as it allows a modular approach to the creation of topic maps and it
provides a means for different users to share and combine their topic maps in a controlled manner.
Topic Maps are very flexible but difficult to evolve, maintain and keep consistent. Furthermore
they have a non-well defined semantics. they represent an informal (or, at least, semi-formal)
approach to knowledge representation. Some work is currently being done on a formal data model for
topic maps (e.g., [92][4]). Despite this lack of formal semantics and the relatively new status of related
standards Topic Maps are used for several Knowledge Management applications. Commercial and
non-commercial implementations of so-called 'topic map engines' are already being offered. These
'engines' have certain features in common - all provide the means to persistently store data structured
as topic maps and to retrieve that data programmatically via an API. Other commercial and noncommercial applications of those engines are also available, including applications to present topic
map data in a user-friendly browser-interface and applications to manually or automatically create topic
maps from data sources.
2.3.5
Concept Maps
Concept Maps (CMap) has been developed by Joseph Novak in the early 70’s[97]. The CMap is a
knowledge representation tool in the form of a graph comprised of boxes connected with labeled arcs.
Words or phrases that denote concepts are put inside the boxes, and relationships between different
concepts are specified on each arc.
Prepositions consist of two or more concepts labels connected by a linking relationship that forms
a semantic unit (node-link-node).
Concepts are defined as “perceived regularities in events or objects, or records of events or
objects, designated by a label”[96]. A significant variation of a proposition is a crosslink, which shows
the relationships between ideas in different segments of the map. Links specify the relationship
between concepts by words or signs/symbols. Arrows are used to designate the directionality of the
relationship; if an arrow is not used, it is assumed that the direction of the relationship is downward.
Novak (1998) emphasized the importance of hierarchical structures in concept mapping. Thus,
CMaps should have more inclusive, general concepts at the top of the hierarchy with progressively
reducing generality at the lower levels, which consist of less inclusive, more specific concepts. Based
on this principle, CMaps are generally read from the top to the bottom.
Concept mapping is based on Ausubel’s theory of learning[5], which emphasized the difference
between meaningful and rote learning. Meaningful learning, the theory argued, builds one’s cognitive
structure by assimilating new concepts into learner’s existing conceptual structure. Novak described
concept mapping as a “major methodological tool of Ausubel’s Assimilation Theory of meaningful
learning.”
Concept Map is supposed mainly to represent static knowledge, primarily for representing “static”
relationships between concepts. An extension to Concept Maps, in order to provide the mean to
express “dynamic” relationships between concepts, is represented by Cyclic Concept Maps (Cyclic
CMaps), which represent the functional relationships among a constellation of concepts. The ability to
represent both static and dynamic relationships in a single map may increases the power of the
representational system.
2.4
Logic-oriented
This category refers to the languages characterised by logical language terms and expressions.
Their modelling construct include for instance:
•
Predicates symbols, function symbols, constants, variables
•
Axioms
•
Logical and sets operators (µ, [, \, : , 8, 9, ))
Furthermore, it is possible to specify extra-logical features for slots/relations (e.g, transitivity).
Finally, these languages are characterised by a formal specification of the semantics (usually
expressed in a model-theoretic form). This allows to implement procedures (tools) for reasoning
support, typically for the detection of possible inconsistencies introduced during the specification of an
ontology, or the discovery of unexpected implied relationships (e.g, implicit superclass/subclass
relations).
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 27 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
The logic-oriented languages that will be taken into consideration in the follow are:
(First Order Logic)
o KIF,
o CycL,
o SCL
•
(Rules Languages),
o LP/Prolog,
o SWRL
•
(Non-classical logics),
o F-Logic,
o Non-Mon, modalities, temporal logics
•
(Description Logics)
•
2.4.1
KIF (Knowledge Interchange Format)
Knowledge Interchange Format (KIF)[45] is a formal language for the interchange of knowledge
among disparate computer programs. Different programs can interact with their users in whatever
forms are most appropriate to their application. A program itself can use for the computation whatever
internal form it prefers for the data it manages.
KIF is neither intended as a primary language for interaction with human users, nor as an internal
representation for knowledge within computer programs.
As an interchange language, KIF assumes a very basic conceptualization of the Universe of
Discourse (UoD) and offers only a very basic syntactic help to the designer.
The conceptualization on which KIF is based views the UoD as composed of objects. The UoD
comprises also all finite lists, all sets of objects of the UoD and all KIF words. This last feature gives to
KIF the ability to express statements about its own statements, and thus to directly express metaknowledge. Interrelationships among objects is expressed through functions and relations, which are
basically sets of finite lists of objects.
A knowledge base in KIF is a (unordered) set of sentences, definitions and rules.
Sentences express facts about the world. KIF allows to express any First-order logic sentence,
and allows free variables to appear in sentences. Rules are used to express legal steps of inference.
KIF also provides for the specification of non-monotonic reasoning rules. Non-monotonic rules
provide the user to express his non-monotonic reasoning policy within the language, in order to draw
conclusions based, for example on the absence of knowledge.
Definitions are used to associate sets of axioms to constants used for denoting objects, relations
or functions. Not that this association does not happen at a metalinguistic level, i.e. a constant
definition does not behave like a macro-substitution. It is a legal sentences in the language that
logically entail equivalence or entailment between the constant and its defining axioms.
The ability to define relations is used in KIF to predefine several useful relation, for example those
between numbers and various relations that express properties of sets and lists of objects.
2.4.2
Cycl
The Cyc [81] project started as common-sense ontology aimed at supporting Artificial Intelligence
applications. In the originary intentions, it should have been a huge repository of general facts,
heuristics and a wide sample of specific facts and heuristics, beliefs, knowledge of respective limited
awareness of what people know, various ways of representing things, knowledge of which
approximations (micro-theories) are reasonable in various context and so on. In a few word, it should
have been able to describe all aspects of human consensus reality knowledge: the facts and concepts
that people know and those that people assume that others know. While this ambitious goal has not
been achieved, Cyc is however a huge knowledge base with nearly two hundred thousand terms and
several dozen hand-entered assertions about/involving each term. Thanks to this vast covering of
terminology, Cyc2 is still used today in various applications.
CycL is the language in which Cyc knowledge base is encoded. It is a formal language derived
from first-order predicate calculus. In order to express common sense knowledge, however, it extends
22
http://www.cyc.com
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 28 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
first order logic, with constructs to handle equality, default reasoning, skolemization, and some secondorder features. CycL also features typing capabilities, i.e. functions and predicates are typed.
The fundamental unit of knowledge of the Cyc Knowledge base is called an assertion, and
consists of a CycL formula and a truth value referring to the formula. Five possible truth values may be
specified. In particular, the truth value may be unknown, or it can be true or false under additional
assumptions. A monotonical truth value is always assumed to hold, while a default truth value usually
holds but is subect to exceptions.
Assertions are grouped into microtheories, that represent sets of assertions sharing set of
assumptions. A microtheory is also called a context[106], as they supply a context in which the truth
value of an assertion may be evaluated. Every assertion also has a justification, that documents why a
certain assertion is present in the KB with a certain truth value (it may have been asserted or inferred).
A CycL formula is constructed over other formulas and terms, logical connectives and quantifiers.
Terms can be divided into constants, non-atomic terms, variables, and a few other types of objects
(numbers, strings, …). Constants may denote either individuals, collections of other concepts (i.e. sets
of the individuals identified by means of unary predicates), arbitrary predicates that allow to express
relationships among constants, or functions, which can take constants or other things as arguments,
and generate new concepts.
A non-atomic term is a way of specifying a term as a function of some other term(s). Every nonatomic term is composed of a function and one or more arguments to that function. Variables stand for
constants whose identities are not specified. A well-formed formula may not contain unbounded
variables.
The syntax of CycL formulas is lisp-like, i.e. a formula is represented as a list starting with a
predicate symbol, connective or quantifier.
2.4.3
SCL (Simple Common Logic - CL working group)
SCL has been designed with several requirements in mind, all arising from its intended role as a
medium for transmitting logical content on the web.
SCL is a family of languages rather than a single language. The different SCL languages, referred
to here as dialects, may differ sharply in their syntax, but they have a single uniform semantics.
Membership in the family is defined by being inter-translatable with the other dialects while preserving
meaning, rather than by having any particular syntactic form. Several existing languages can be
considered to be SCL dialects.
One SCL dialect plays a special role. The XML syntax for SCL (called XCL) is designed to serve
three functions. It is a standard intercommunication notation for machine use on a network; it is the
single 'reference syntax' into which all other dialects can be translated or embedded, and relative to
which the SCL semantics is defined; and it provides forms which can be used to express various
extensions and relations to existing standards and to support existing conventions regarding URI
usage. XCL syntax follows conventional XML usage and is partly inspired by MathML. It is not
intended to be compact or human-readable. This document also independently defines a more
conventional dialect, SCL Core, which is intended to be compact, human-readable and more similar to
conventional machine-oriented logics, notably to KIF. SCL Core syntax is used in giving examples.
2.4.4
LP/Prolog
Prolog3 [139] which stands for PROgramming in LOGic, is the most widely available language in
the logic programming paradigm. Logic and therefore Prolog is based the mathematical notions of
relations and logical inference. Prolog is a declarative language meaning that rather than describing
how to compute a solution, a program consists of a data base of facts and logical relationships (rules)
which describe the relationships which hold for the given application. Rather then running a program to
obtain a solution, the user asks a question. When asked a question, the run time system searches
through the data base of facts and rules to determine (by logical deduction) the answer.
Among the features of Prolog are logical variables meaning that they behave like mathematical
variables, a powerful pattern-matching facility (unification), a backtracking strategy to search for proofs,
uniform data structures, and input and output are interchangeable.
3
http://cs.wwc.edu/~cs_dept/KU/PR/Prolog.html#ref
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 29 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Often there will be more than one way to deduce the answer or there will be more than one
solution, in such cases the run time system may be asked find other solutions. backtracking to
generate alternative solutions. Prolog is a weakly typed language with dynamic type checking and
static scope rules.
Prolog is used in artificial intelligence applications such as natural language interfaces, automated
reasoning systems and expert systems. Expert systems usually consist of a data base of facts and
rules and an inference engine, the run time system of Prolog provides much of the services of an
inference engine.
2.4.5
SWRL
Semantic Web Rule Language (SWRL) is based on a combination of the OWL DL and OWL Lite
sublanguages of the OWL Web Ontology Language (see Section 2.6.4) with the Unary/Binary Datalog
RuleML sublanguages of the Rule Markup Language [136]. SWRL includes a high-level abstract
syntax for Horn-like rules in both the OWL DL and OWL Lite sublanguages of OWL.
The proposed rules are of the form of an implication between an antecedent (body) and
consequent (head). The intended meaning can be read as: whenever the conditions specified in the
antecedent hold, then the conditions specified in the consequent must also hold.
Both the antecedent (body) and consequent (head) consist of zero or more atoms. An empty
antecedent is treated as trivially true (i.e. satisfied by every interpretation), so the consequent must
also be satisfied by every interpretation; an empty consequent is treated as trivially false (i.e., not
satisfied by any interpretation), so the antecedent must also not be satisfied by any interpretation.
Multiple atoms are treated as a conjunction. Note that rules with conjunctive consequents could easily
be transformed (via the Lloyd-Topor transformations [137]) into multiple rules each with an atomic
consequent.
Atoms in these rules can be of the form C(x), P(x,y), sameAs(x,y) or differentFrom(x,y), where C is
an OWL description, P is an OWL property, and x,y are either variables, OWL individuals or OWL data
values. It is easy to see that OWL DL becomes undecidable when extended in this way as rules can
be used to simulate role value maps [138].
Informally, an atom C(x) holds if x is an instance of the class description C, an atom P(x,y) holds if
x is related to y by property P, an atom sameAs(x,y) holds if x is interpreted as the same object as y,
and an atom differentFrom(x,y) holds if x and y are interpreted as different objects. Note that the latter
two forms can be seen as "syntactic sugar": they are convenient, but do not increase the expressive
power of the language (i.e., such (in)equalities can already be expressed using the combined power of
OWL and rules without explicit (in)equality atoms).
There are two SWRL concrete syntax, one is based on RDF (see Section 2.6.3) and the other is
based on OWL. The latter is a combination of the OWL Web Ontology Language XML Presentation
Syntax with the RuleML XML syntax. This has several advantages:
•
arbitrary OWL classes (e.g., descriptions) can be used as predicates in rules;
•
rules and ontology axioms can be freely mixed;
•
interoperability between OWL and RuleML is simplified, existing RuleML tools can be adapted to
SWRL
2.4.6
F-Logic (M. Kifer, G. Lausen, J. Wu)
F-logic or Frame logic [76] is a logical formalism that tries to capture the features of objectoriented approaches to computation and data representation.
It has been developed in order to bridge the gap between object-oriented computing and data
representation systems and deductive databases, providing theoretical bases for an object-oriented
logic programming language to be used either as a computing tool and as a data representation tool.
Though F-logic is mainly aimed at the representation of object-oriented databases, it is also
suitable for representation of knowledge in a frame-based fashion, as frame-based KRS share with
object-oriented representation formalisms the central role of complex objects, inheritance and
deduction. The name of the language itself is due to this connection with Frame-based languages.
F-logical syntactical framework is not too much dissimilar to that of FOL. As in FOL, the most
basic constructs of the language are terms, composed of function symbols, constants and variables.
Formulas are constructed from terms with a variety of connectives.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 30 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Anyway, elements of the language are intended to represent properties of objects and relations
about objects. Terms play the role of logical object ids. They are used to identify objects and access
their properties. Function symbols play the role of object constructors. Formulas allow building
assertions over objects. In particular, the simplest kind of formulas, called F-molecules, allow asserting
either a set of properties for an object, a class-membership relation between two objects or a
superclass-subclass relationship between two objects. For example, if O is a term, the syntax O:E
represents the fact that O is an instance of E, O::E means that O is a superclass of E and the formula
O[semicolon separated list of “method expressions”]
Allows to associate various properties to the object denoted by O. Method expressions allow
specifying properties that correspond, in an object oriented view, to attributes, methods or signatures.
Methods consist of a name, a set of arguments and a return value, which may be scalar or set-valued.
Attributes are just methods that don’t take any argument. Attributes and method may be specified to be
inheritable. Inheritable methods assertions on an object are propagated to objects that are in is-a
relationship with the first one, though with a difference between the two kinds of isa: inheritable
expressions become not inheritable in member objects. A signature expression specifies a type
constraint on the arguments and results of a method. Signatures are used for type checking and are
enforced, that is specifying a method without declaring a signature for it raises a type error.
Notice that everything in F-logic is built around the concept of object. There is no distinction
between classes and individual objects: they both belong to the same domain. In its most basic
version, F-logic doesn’t make any distinction between complex objects and atomic values, either.
F-logic is a logic with model-theoretic semantics. Semantics for the F-language are given in terms
of F-structures and satisfaction of F-formulas by F-structures, and a notion of logical entailment is
given. In [76], a resolution-based proof theory for F-logic is provided. A deductive system consisting of
twelve inference rules and one axiom is provided and it’s proved to be sound and complete.
Anyway, F-logic’s intended use is as a logic programming language, to be used both as a
computational formalism and as a data specification language. [76] describes Horn F-programs, which
are made of the equivalent of Horn rules in F-logic, and generalized Horn F-programs. As in classic
logic programming, the semantics of Horn F-programs is based on the concept of least models. For a
class of generalized programs, a unique canonic model may also be found, in a way similar to that
used to define semantics of locally stratified programs in classic logic programming.
Note that the syntactic rules defined for F-logic and its deductive system cannot really enforce that
in type-constraint stated with signature rules hold in a canonic model of an F-program. In [76], an
additional semantic formalization of type rules is given in order to justify the use of static type checking.
Frame logic’s syntax has some higher-order features. Despite this higher order syntax, the
underlying semantic formally remains first order, which allows avoiding difficulties normally associated
with higher order theories.
2.4.7
Description Logics (a family of languages)
Description Logics (DLs) are a family of logic-based knowledge representation formalisms
designed to represent and reason about the knowledge of an application domain in a structured and
well-understood way. DLs differ from their predecessors, such as semantic networks and frame based
systems, in that they are equipped with formal, logic-based semantics.
The basic notions in DLs are concepts and roles, which denote sets of objects and binary
relations, respectively. Complex concept expressions and role expressions are formed by starting from
a set of atomic concepts and atomic roles, i.e., concepts and roles denoted simply by a name, and
applying concept and role constructs. Thus, a specific DL is mainly characterized by the constructors it
provides to form such complex concepts and roles.
An ontology can be expressed in a DL by introducing two components, traditionally called TBox
and ABox (originally from “Terminological Box” and “Assertional Box” respectively)4. The TBox stores
a set of universally quantified assertions, stating general properties of concepts and roles. Indeed
4
Since TBox and ABox constitute two different components of the same knowledge base,
sometimes[41] this kind of systems have been also called hybrid. However, we prefer here to
distinguish between terminological/assertional hybrid systems in which any of the subsystems may be
empty, that we call pure DL systems, and more general hybrid systems that will be presented below.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 31 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
concepts (or roles) are defined intensionally, i.e. in terms of descriptions that specify the properties that
objects must satisfy to belong to the concept (or pairs of objects must satisfy to belong to the role). The
ABox comprises assertions on individual objects, called instance assertions, that consist basically of
memberships assertions between objects and concepts (e.g. a is an instance of C), and between pairs
of objects and roles (e.g. a is related to b by the role R).
Several reasoning tasks can be carried out on a knowledge base of the above type, in order to
deduce implicit knowledge from the explicitly represented knowledge. The simplest forms of reasoning
involve computing: i) subsumption relation between two concept expressions, i.e. verifying whether
one expression always denotes a subset of the objects denoted by another expression, ii) instance-of
relation, i.e. verifying whether an object o is an element denoted by an expression, and iii) consistency
algorithm, i.e. verifying whether a knowledge base is non-contradictory.
In order to ensure a reasonable and predictable behaviour of a DL system, these inference
problems should at least be decidable for the DL employed by the system, and preferably of low
complexity. Consequently, the expressive power of the DL in question must be restricted in an
appropriate way. If the imposed restrictions are too severe, however, then the important notions of the
application domain can no longer be expressed. Investigating this trade-off between expressivity of
DLs and the complexity of their deduction capabilities has been one of the most important issues in DL
research.
Several languages based on description logics exist. Beside “pure” description logic languages,
It is worthwhile to mention systems and languages that build up on DL languages.
While very powerful at specifying a description of the domain of interest, DL languages have
several limitations on how these descriptions may be queried. In particular, a knowledge base is able
to answer only queries that return subsets of existing objects, rather than creating new objects.
Furthermore, the selection conditions are rather limited. Hybrid languages address the problem of
specifying complex queries against Knowledge Bases based on DLs. For example the AL-Log[29]
system mixes a DL-style knowledge with the expressive power of a relational query language like
Datalog. It provides extensions of the Datalog language that allows for the expression of clauses with
constraints expressed with ALC. The constraints on the variables require them to range over the set of
instances of a specified concept, while the constraints on individual objects require them to belong to
the extension of a concept. Therefore DLs is used as a typing language on the variables appearing in
the rules, and only unary predicates from the DLs are allowed in the rules.
Other languages, notably languages explicitly designed for ontology representation, have
semantics defined via a translation into an expressive DL. An example of such a language is OWL. For
a comprehensive discussion on DLs, see [4][126].
2.5
Frames-oriented
This category refers to the languages based on the Frames paradigm: the main modelling notions
are Frame, Slot and Facet.
A Frame is a named data structure which is used to represent some concept in a domain; it allows
to group related statements about that concept. Associated with each frame is a group of slots, facets,
and respective values. Slots are used to describe (binary) relationship between concepts. Facets are
used to represent information about a slot in an object (e.g., to specify some constraint over the slot).
The modelling paradigm of frame-oriented languages is very similar to object oriented
programming languages with the notion of class inheritance at their heart.
NOTE: Logic vs Frame –oriented
The central modeling primitive of predicate logic are predicates; unary predicates represent
entities, binary (n-ary) predicates represent relationships (properties and attributes). In this case,
attributes have a global scope.
Frame-based and object-oriented approaches have entities (i.e., classes, frames) as their central
notion. Properties (attributes) are ancillary to entities. Their specifications are local to (and depend on)
entity specification: attributes are only applicable to the classes which they are defined for (they are
typed); the “same” attribute (i.e., the same attribute name) may be associated with different range and
value restrictions when defined for different classes (i.e., the domain determines the semantics).
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 32 / 244
IP- Project
ATHENA -Project
Document
•
•
•
•
•
•
•
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Some frames-oriented languages:
Frame Systems,
OKBC,
XOL,
SHOE,
Ontolingua
OCML
OIL,
2.5.1
Frame Systems
A widely investigated and used paradigm for knowledge representation is that based on the
concept of Frames. A frame is a data structure that provides a representation of an object or a class of
objects or a general concept or predicate.
Frames have components called slots. The slots of a frame describe attributes or properties of the
thing represented by that frame and can also describe binary relations between that frame and another
frame. In the simplest model of a slot, it has a name and a value. In addition to storing values, slots
often also contain restrictions on their allowable values, in terms of data types and/or ranges of
allowable values. They may also have other components in addition to the slot name, value and value
restrictions, for instance the name of a procedural attachment than can be used to compute the value
of the slot (usually referred to as "daemons"). These different components of a slot are usually called
its facets.
Typical frame-based systems allow to organize frames that represent classes into taxonomies. In
a taxonomic hierarchy, each frame is linked to one or, in some systems, more than one parent frame.
Through taxonomic relations, classes may be described as specializations of other more generic
classes. Classes in a taxonomy inherit from their super classes features like slot definitions.
The way in which inheritance is implemented may differ from system to system.
Another fundamental feature of the Frame-based approach is that of prototypes. The description
of a class or concept can contain a prototype description of instances of that class or concept. These
means that default values are specified for slots.
When the system handles an object, it may first look if specific values are available (i.e. have been
explicitly specified by a user or procedure). If they are, then they can be assumed to be the most
reliable and up-to-date value for slots. Otherwise, slot values defaults to those of the prototype.
Usually, a prototypical objects stands at the top of a hierarchy. Default values defined for this
prototype are propagated through the inheritance chain to subclasses. In this way, when a slot is
examined, in the absence of additional information the system looks at successive ancestors of the
frame in question and attempt to inherit values or appropriate procedural attachments which have
been asserted into one of these frames.
The Frame-based approach has been used in a variety of different implemented systems. While
basic concepts remain the same for all those systems, there is usually a certain diversity in
terminology used or in other features. For example, whereas some systems define only a single type
of frame, other systems distinguish two or more types, such as class frames and instance frames.
Slots may also be typed, or treated as frames themselves.
2.5.2
OKBC
OKBC (Open Knowledge Base Connectivity)[20][21] is an API aiming at providing a standardized
access to different knowledge bases and models .
It is based on a Frame oriented conceptualization, and thus provides access to different
knowledge bases through operations that are typical of Frame based systems, such as find a frame
matching a name, enumerate the slots of a frame, delete a frame etc.
This underlying, implicit conceptualization is called the OKBC knowledge model. It supports a
wide set of representational constructs that are typically found in frame-based knowledge
representation systems. In particular, it supports the concept of frame, as a primitive object that
represents an entity in the domain of discourse. A frame is associated with a set of own slots, and
each own slot of a frame has associated with it a set of entities called slot values. An own slot of a
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 33 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
frame is associated with a set of own facets, and each own facet of a slot of a frame has associated
with it a set of entities called facet values.
The concept of class is also supported. A class is represented through a frame. A frame that
represents a class is called a class frame, and a frame that represents an individual is called an
individual frame. A class is a set of entities. Each of the entities in a class is said to be an instance of
the class. An entity can be an instance of multiple classes, which are called its types. A class can be
an instance of a class. A class that has instances being themselves classes is called a meta-class.
Entities that are not classes are referred to as individuals. A class frame has associated with it a
collection of template slots that describe own slot values considered to hold for each instance of the
class represented by the frame. The values of template slots are said to inherit to the subclasses and
to the instances of a class. Template slots and template facets have a set of default values associated
with them. These default values inherit to instances unless the inherited values are logically
inconsistent with other assertions in the KB, the values have been removed at the instance, or the
default values have been explicitly overridden by other default values.
A knowledge base (KB) is a collection of classes, individuals, frames, slots, slot values, facets,
facet values, frame-slot associations, and frame-slot-facet associations. KBs are considered to be
entities in the universe of discourse and are represented by frames. Frames are also in the universe
of discourse, as well as slot and facets. The OKBC model is itself defined as a set of KIF axioms.
2.5.3
XOL
XOL[72] is an intermediate language for transferring ontologies among different database
systems, ontology-development tools, or application programs. Its syntax is based on XML, and its
semantics are defined as a simplified subset of the OKBC knowledge model, called OKBC-Lite. A main
difference with the OKBC knowledge model resides in that the notion of ``frame'' has been eliminated.
The ontology building blocks defined by the OKBC-Lite Knowledge Model include classes, individuals,
slots, facets, and knowledge bases. Classes and individuals stand for themselves and are not
represented through frames.
Thus, the basic construct to define concept is that of Class. As in OKBC, a class is a set of
entities. Each of the entities in a class is said to be an instance of the class. An entity can be an
instance of multiple classes, which are called its types. A class can be an instance of another class. A
class that has instances that are themselves classes is called a meta-class. Entities that are not
classes are referred to as individuals. Thus, the domain of discourse consists of individuals and
classes.
The OKBC-Lite knowledge model assumes that every class and every individual has a unique
identifier, also known as its name. The name may be a string or an integer, and is not necessarily
human readable. The concept of own slot is transferred to both classes and individuals.
Essentially, XOL is a markup syntax to transfer OKBC-lite knowledge bases. This syntax is
defined in an appropriate DTD. In addition to this DTD the specifications give additional well-formness
rules for XOL documents. These rules regard, for example, uniqueness of names and order between
elements.
In the specification, the authors put a great emphasis on the fact that XOL can describe any and
every ontology with a single set of XML tags (described by a single XML DTD).
A XOL document models both classes and instances together.
This approach, which the authors call a “generic approach”, is opposed to that of defining a
the schema portion of the ontology, use it to generate an XML DTD or Schema, and than using it
to describe valid documents that only contain the data portion of the ontology (i.e. instances).
2.5.4
SHOE
SHOE is an extension of HTML which adds the tags necessary to embed arbitrary semantic data
into WWW pages. SHOE tags are divided into two categories. First, there are tags for constructing
ontologies. SHOE ontologies are sets of rules which define what kinds of assertions SHOE documents
can make and what these assertions mean. Secondly, there are tags for annotating SHOE documents
to subscribe to one or more ontologies, declare data entities, and make assertions about those entities
under the rules prescribed by the ontologies.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 34 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
to HTML which makes it possible for authors to include machine-readable semantic knowledge in
World Wide Web documents. It includes mechanisms for hierarchical classification and for specifying
relationships between elements and data. SHOE makes it possible for intelligent agents to gather
information about web pages and other documents more intelligently, and thus to improve searching
and knowledge-gathering.
to HTML which allows web page authors to annotate their web documents with machine-readable
knowledge. SHOE makes real intelligent agent software on the web possible. HTML was never meant
for computer consumption; its function is for displaying data for humans to read. The "knowledge" on a
web page is in a human-readable language (usually English), laid out with tables and graphics and
frames in ways that we as humans comprehend visually. Unfortunately, intelligent agents aren't
human. Even with state-of-the-art natural language technology, getting a computer to read and
understand web documents is very difficult. This makes it very difficult to create an intelligent agent
that can wander the web on its own, reading and comprehending web pages as it goes. SHOE
eliminates this problem by making it possible for web pages to include knowledge that intelligent
agents can actually read.
At the time of publication, SHOE represented a novel way of annotating web pages to add
semantic information. However, SHOE has now been superceded by XML.
2.5.5
Ontolingua
The name Ontolingua([49][50][36]) denotes both a System for the management of portable
ontology specifications and the language therein used.
The Philosophy underlying it is that to enable interoperability among different implemented
knowledge representation systems it is better to model ontologies in a common, highly expressive
language with clearly defined semantics and then translate the specification to the languages or
formalisms used in the implemented systems. The translation might not be complete, as it is limited by
the actual expressive power of the target systems.
The Ontolingua language itself, on the other hand, is not designed to be used as an internal
format for any real systems for knowledge representation and reasoning.
The Ontolingua language is based over KIF (see Section 2.4.1). KIF has precise syntax, well
defined semantics, it is highly expressive and is independent of any specific KR system. As such, it is
a good choice for a common language for knowledge representation.
However, the conceptualization behind KIF is very general, and the language constructs it offers
are too fine grained, being essentially those of straight predicate calculus. KIF is far too expressive to
be directly handled by any implemented KRS. Furthermore, KIF is not designed to be used as a
modeling language. As such, it does not offer direct syntactic support for high level modeling or to add
documentation. On the contrary, most real KR systems offer high level syntactic primitives, which are
usually bounded to object-oriented or Frame based conceptualizations of the world.
As Ontolingua is aimed at being an interlingua for existing real KRS, it must allow users to specify
ontologies with a familiar style. This helps both the ontology designer and the developer of a
translation module.
To meet this purpose, Ontolingua substitutes KIF’s definitional forms (which allow for the definition
of functions, relations and objects) with a set of other definitional forms based on a conceptualization
which is close in spirit to that of Frame-based systems and of Object-oriented Systems.
Ontolingua definitional forms are actually LISP macros that act as wrappers around sets of KIF
sentences. At a logical level, Ontolingua definitions are equivalent to set of KIF sentences (and they
may be easily translated into their KIF equivalents, which are used for internal treatment).
They allows to associate a symbolic name to a textual string (for documentation), a set of
variables and a set of KIF axioms holding on the constant. Forms are provided to define this way
relations, classes, functions, objects and theories (the name theory denote sets of Ontolingua
definitions in the Ontolingua terminology). Axioms may be specified through a subset of KIF.
Beside this addition of syntactic primitives, the conceptualization underlying Ontolingua is
captured by an ontology (which is itself an Ontolingua theory) called the Frame-ontology. The Frame
ontology defines concepts used in an Ontolingua ontology definition, like that of class, slot etc,
associating them precise semantics through KIF axioms.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 35 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
One can think of KIF plus the Frame ontology as a specialized representation language.
The basic ontological commitments of the Frame-ontology, with respect to the conceptualization
underlying KIF, are the following:
•
Relations are sets of tuples
•
Functions are a special case of relations
•
Classes are unary relations
•
Extensional semantics for classes
•
No special treatment of slots, just binary relations and unary functions
•
KL-ONE style specs are relations on relations (second-order relations, not meta-linguistic or
modal)
Definitional forms serve as a mean to guide the developer in specifying axioms consistently with a
conceptualization of modeling construct, which is inherently frame-oriented. Imposing a structure on
the definitions used in the ontologies helps the translation task and guides a user in specifying portable
ontologies.
Second order terms defined in the Frame Ontology may be used during modeling (for example, in
the context of definition forms) as a compact representation for their first order equivalents. The
canonical form produced by Ontolingua during translations is based on these second order relations.
Ontolingua is capable of recognizing different variants of expanded forms of these relations and
converting them to their compact form. This helps overcome stylistic differences among different
ontologies. The terms contained in the Frame Ontology are the only second-order constructs for which
Ontolingua guarantees translation to the target implemented systems. Defining these constructs in a
separate way allows to improve translation, as they are usually linked to special, ad hoc constructs
found in the target languages. To help developers, various definition styles and syntactic variants are
allowed. Ontologies defined with this language are then normalized translating them into a single,
canonical form and passed to different modules that perform the task of translating them to specific
system’s representation languages or formalisms.
2.5.6
OCML
OCML[92] is a knowledge modeling language aimed at support knowledge level modeling while
providing also support for development of implemented knowledge-based systems.
It has been largely inspired by Ontolingua and shares many similarities with it.
OCML’s syntax, similarly to that of Ontolingua, is defined by a mixture of LISP style definitional
forms and KIF syntax. Indeed, OCML’s main modeling facilities closely resemble those of Ontolingua.
Furthermore, it has a pre-built base-ontology that has a role closely similar to that played by the
Frame-Ontology in Ontolingua.
However, OCML is aimed at prototyping KB applications. For this resons, it has some substantial
differences from Ontolingua. It has operational semantics. Semantics of those primitives that are
directly related to that of ontolingua is defined both with Ontolingua (KIF) axioms and operationally.
Other constructs of the language only have operational semantics.
In particular, OCML adds facilities to enable interactive theorem proving, constraint checking,
function evaluation, evaluation of forward and backward rules. It also provides non-logical facilities
such as procedural attachments. These features offer allow an alternative approach to the
development of knowledge based applications and simplify fast-prototyping.
Another fundamental difference is that
Other substantial differences come from the fact that OCML is not only aimed at representing
terminological knowledge, but also behavior. This is supported by primitives that allow to specify
control structures, and is reflected in the base-ontology, that also defines terms needed for task and
method modeling.
The syntax of OCML is based on three basic constructs, namely functional terms, control terms
and logical expressions. Functional terms and logical expressions may be used to specify relations,
functions, classes, slots, instances, rules, and procedures. Relations, function, classes, slot,
procedures and rules definitions allow to specify semantics mixing constructs with formal and
operational meaning. Furthermore, some constructs play both-role. For example, in the context of a
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 36 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
relation definition, the iff-def keyword specifies that a necessary and sufficient condition hold. It also
implies that the condition may be used to enforce a constraint and that the proof mechanisms may be
used to decide whether or not the relation holds for some arguments. Procedures define actions or
sequences of actions that cannot be characterized as functions between input and output arguments
(for instance, updates on slot values).
OCML implementations supports an interactive tell/ask interface. The same keywords used to
interact with this shell are also used in procedures definitions to specify changes in a KB.
2.5.7
OIL (Ontology Inference Layer)
Developed with the purpose of synthesizing the work from three different communities (Framebased systems, Description Logics and Web standards) to provide a general purpose markuplanguage for the Semantic Web.
It is the first web-based representation language for ontologies definition, which combines the
widely used modelling primitives from frame-based languages with the formal semantics and
reasoning services provided by description logics.
OIL is the first ontology representation language that is properly grounded in W3C standards such
as RDF-RDF schema and XML-XML schema; developed from the need of a standard for specifying
and exchanging ontologies; it is an evolution of existing proposals such as OKBC, XOL, RDF.
2.6
Web-oriented
With the advent of the Semantic Web, new exigencies have been identified, such as the possibility
of interchanging ontologies across the World Wide Web (WWW) and enabling the cooperation among
heterogeneous agents placed on the WWW. For these reasons, a new set of ontology specification
languages, based on new web standards such as XML, has been developed.
These languages are aimed at representing the knowledge contained in an ontology in a simple
and human-readable way and allow for the interchange of ontologies across the web.
•
•
•
•
Some web-oriented languages
XML Schema,
DAML+OIL,
RDF(S),
OWL
2.6.1
XML Schema (W3C consortium)
XML-Schema[129] is a schema language for XML documents. An easily readable description of
the XML Schema facilities can be found in [35]. For a formalization of the essence of XML-Schema
see [112].
Similarly to DTD, it allows to define schemas that model the structure of classes of XML
documents, i.e. a set of structural constraints that documents must satisfy in order to be considered
valid with respect to the schema itself.
XML-Schema is far more complex than the DTD language, allowing for the specification of much
more elaborated constraints on how different part of an XML document fit together. In particular, it
adds more sophisticated nesting rules, supports a namespacing mechanism and a full-blown data
type system.
The possibility to structure documents into complex nested forms, together with the ability to
define complex types and to mix definitions coming from different schema documents without
ambiguity (due to the namespacing mechanism) together may be seen as a basic form of knowledge
representation mechanism. In particular, the rich set of primitive data-types and of complex types
definition mechanisms seem to allude to knowledge representation capabilities.
This type system has been designed in order to allow applications to verify validity of documents
in a more sophisticate manner than what DTD made possible.
XML-Schema, however, was not designed as a general purpose ontology representation
language. Its purpose its only to constrain XML documents from a syntactical point of view. The data
model underlying XML schema is only capable of representing valid instances of XML documents.
There is no formal semantics defined, and no relation of any sort with real world objects.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 37 / 244
IP- Project
ATHENA -Project
Document
2.6.2
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
DAML+OIL
DAML+OIL is a semantic markup language for Web resources[26]. It builds on W3C standards
such as RDF and RDF Schema, and extends these languages with richer modelling primitives.
DAML+OIL provides modelling primitives commonly found in frame-based languages. DAML+OIL
(March 2001) extends DAML+OIL (December 2000) with values from XML Schema datatypes.
DAML+OIL was built from the original DAML ontology language DAML-ONT (October 2000) in an
effort to combine many of the language components of OIL (see Section 2.5.7). The language has a
clean and well defined semantics.
A DAML+OIL knowledge base is a collection of RDF triples. DAML+OIL prescribes a specific
meaning for triples that use the DAML+OIL vocabulary. Any additional RDF statements, resulting in
additional RDF triples are perfectly allowed, but DAML+OIL is silent on the semantic consequences (or
lack thereof) of such additional triples.
DAML+OIL divides the universe into two disjoint parts. One part consists of the values that belong
to XML Schema datatypes. This part is called the datatype domain. The other part consists of
(individual) objects that are considered to be members of classes described within DAML+OIL (or
RDF). This part is called the object domain.
DAML+OIL is mostly concerned with the creation of classes that describe (or define) part of the
object domain. Such classes are called object classes and are elements of daml:Class, a subclass of
rdfs:Class. DAML+OIL (March 2001) also allows the use of XML Schema datatypes to describe (or
define) part of the datatype domain. These datatypes are used within DAML+OIL simply by including
their URIs within a DAML+OIL ontology. They are (implicitly) elements of daml:Datatype. Datatypes are
not DAML+OIL individual objects.
2.6.3
RDF(S)
The Resource Description Framework (RDF) [84] [79] [15] is an XML language that may be used
to describe resources and relaations about them over the world wide web. This does not mean that
these resources may be retrived over the web, but only that they can be identified on the web,
particularly with a URI reference (which is an URI whith an optional fragment identifier).
It is particularly intended for representing metadata in a way that is readable both to software and
human agents.
RDF is based on a simple data model, that has some resemblances with that of CG. In the RDF
model, resources are identified by URI references. A property is a is a specific aspect, characteristics,
attribute, or relation used to describe a resource.
Properties and their values are related to resources through statements. Statements are triples of
the form <thing><property><value> (but these three components of a statement are often referred to
as <subject> <predicate> <object>).
A thing is a resource that can be described by some property. A predicate defines the type of
property that is being attributed. Finally, the object is the value of the property associated with the
subject. Property values may be values from some concrete domain (called literals) or themselves be
resources identified by URIs. This means that a set of RDF statements may be seen as a graph in
which resources are nodes and properties are edges. For this reason, a collection of RDF statements
is also called a RDF graph. Asserting multiple statements with the same subject has the meaning to
define several properties for the same resource, and in general an RDF graph asserts the conjunction
of the statements corresponding to all the triples it contains. RDF does not have any syntactic
mechanism to express disjunction or negation.
While RDF statements allow to define only binary relations between resources, more complex (nary) relations may be express through blank nodes, which are nodes that not have an URI reference.
Note that properties are also identified by URI references. This allows to add an external meaning
to the property, by referencing an appropriate resource. This also mean that properties are in turn
considered as resources, and thus RDF allow expressing statements about them, thus providing a
form of reification.
RDF has a formal model-theoretic semantics[57] which provides a basis for reasoning about the
meaning of an RDF expression. In particular, it defines a rigorously defined notions of entailment.
Semantics of an RDF graph are defined by associating an interpretation to the vocabulary of the
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 38 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
graph, that is the set of names (URIs and literals) that appear therein. Ground RDF Graphs, that is
graphs that do not contain blank nodes, may be given a truth value with regard to an interpretation of
their vocabulary. Blank nodes are treated as simply indicating the existence of a thing, without using,
or saying anything about, the name of that thing. That is, all blank nodes are treated as having the
same meaning as existentially quantified variables.
RDF itself defines a syntax and a simple data model to talk about resources. This data model
cannot itself be considered as an ontology language. RDFS is an extension to RDF that defines a way
to use RDF to define vocabularies, in a way the fixes the interpretation of parts of the RDF language.
RDF Schema (RDFS) [14] enriches the basic RDF model, by providing a vocabulary for RDF,
which is assumed to have a certain semantics. Predefined properties can be used to model instance of
and subclass of relationships as well as domain restrictions and range restrictions of attributes. Indeed,
the RDF schema provides modeling primitives that can be used to capture basic semantics in a
domain neutral way. That is, RDFS specifies metadata that is applicable to the entities and their
properties in all domains. The metadata then serves as a standard model by which RDF tools can
operate on specific domain models, since the RDFS metamodel elements will have a fixed semantics
in all domain models.
RDFS provides simple but powerful modeling primitives for structuring domain knowledge into
classes and sub classes, properties and sub properties, and can impose restrictions on the domain
and range of properties, and defines the semantics of containers.
The simple meta modeling elements can limit the expressiveness of RDF/S. Some of the main
limiting deficiencies are identified in [77]:
•
Local scope of properties: in RDFS it is possible to define a range on properties, but not so they
apply to some classes only. For instance the property eats can have a range restriction of food
that applies to all classes in the domain of the property, but it is not possible to restrict the range
to plants for some classes and meat for others.
•
Disjointness of classes can not be defined in RDF/S.
•
Boolean combinations of classes is not possible. For example person cannot be defined as the
union of the classes male and female.
•
Cardinality restrictions cannot be expressed.
•
Special characteristics of properties like transitivity cannot be expressed.
Because of these inherent limitations, RDF(S) has been extended by more powerful ontology
languages. The currently endorsed language is the Web Ontology Language (OWL) which has been
discussed in Section 2.6.4.
2.6.4
OWL (Ontology Web Language) Æ scheda
The Web Ontology Language OWL is a semantic markup language for publishing and sharing
ontologies on the World Wide Web. OWL extends RDF and RDF Schema by providing additional
vocabulary along with a formal semantics (equivalent to very expressive Description Logic, an
extension of SHIQ DL). It has its foundations into the DAML+OIL and it also provides built-in ontology
mapping support.
•
•
•
OWL is a set of three, increasingly complex languages.
Owl Lite has been defined with the intention of creating a simple language that will satisfy users
primarily needing a classification hierarchy and simple constraint features.
OWL DL includes the complete OWL vocabulary, interpreted under a number of simple
constraints. Primary among these is type separation. Class identifiers cannot simultaneously be
properties or individuals. Similarly, properties cannot be individuals. OWL DL is so named due to
its correspondence with Description Logics.
OWL Full includes the complete OWL vocabulary, interpreted more broadly than in OWL DL, with
the freedom provided by RDF. In OWL Full a class can be treated simultaneously as a collection
of individuals (the class extension) and as an individual in its own right (an instance of the second
order).
Intuitively, OWL can represent information about categories of objects and how objects are
interrelated. It can also represent information about objects themselves. More precisely, on the one
side, OWL let describe classes by specifying relevant properties of objects belonging to them. This
can be achieved by means of a partial (necessary) or a complete (necessary and sufficient) definition
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 39 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
of a class as a logical combination of other classes, or as an enumeration of specified objects. OWL let
also describe properties and provide domains and ranges for them. Domains can be OWL classes,
whereas ranges can be either OWL classes or externally-defined datatypes (e.g. string or integer).
Moreover, OWL let provide restrictions on how properties behave that are local to a class. Thus, it is
possible to define classes where a particular property is restricted so that (i) all the values for the
property in instances of the class must belong to a certain class or datatype (universal restriction), (ii)
at least one value must come from a certain class or datatype (existential restriction), and (iii) there
must be at least or at most a certain number of distinct values (cardinality restriction). On the other
side, OWL can also be used to restrict the models to meaningful ones by organizing classes in a
“subclass” hierarchy, as well as properties in a “subproperty” hierarchy. Other features are the
possibility to declare properties as transitive, symmetric, functional or inverse of other properties, and
couple of classes or properties as disjoint or equivalent. Finally, OWL represents information about
individuals, providing axioms that state which objects belong to which classes, what the property
values are of specific objects and whether two objects are the same or are distinguished.
OWL is quite a sophisticated language. Several different influences were mandated on its design.
The most important are DLs, the frames paradigm and the Semantic Web vision of a stack of
languages including XML and RDF. On the one hand, OWL semantics is formalised by means of a DL
style model theory. In particular, OWL is based on the SH family of Description Logics [62], which is
equivalent to the ALC DL (see Section 2.4.7) extended with transitive roles and role hierarchies. Such
family of languages represents a suitable balance between expressivity requirements and
computational ones. Moreover, practical decision procedures for reasoning on them are available, as
well as implemented systems such as FaCT[60] and RACER[56]. On the other hand, OWL formal
specification is given by an abstract syntax, that has been heavily influenced by frames and constitutes
the surface structure of the language. Class axioms consist of the name of the class being described,
a modality indicating whether the definition of the class is partial or complete, and a sequence of
property restrictions and names of more general classes, whereas property axioms specify the name
of the property and its various features. Such a frame-like syntax makes OWL easier to understand
and to use. Moreover, axioms can be directly translated into DL axioms and they can be easily
expressed by means of a set of RDF triples (cf. Section 2.6.3). This property is an essential one, since
OWL was also required to have RDF/XML exchange syntax, because of its connections with the
Semantic Web.
Given the huge number of requirements for OWL and the difficulty of satisfying all of them in
combination, three different versions of OWL have been designed:
OWL DL, that is characterized by an abstract frame-like syntax and a decidable inference; it is
based on SHOIN(D) DL, which extends SH family of languages with inverse roles, nominals (which
are, in their simplest form, special concept names that are to be interpreted as singleton sets),
unqualified number restrictions and support for simple datatypes; SHOIN(D) is very expressive but
also difficult to reason with, since inference problems have NEXPTIME complexity;
OWL Lite, that constitutes a subset of OWL DL that is similar to SHIF(D) and, as such, it does not
allow to use nominals and allows only for unqualified number restrictions in the form ≤1 R; inference
problems have EXPTIME complexity and all OWL DL descriptions can be captured in OWL Lite, except
those containing either individuals names or cardinalities greater than 1;
OWL Full, that, unlike the OWL DL and OWL Lite, allows classes to be used as individuals and
the language constructors to be applied to the language itself; it contains OWL DL but goes beyond it,
making reasoning undecidable; moreover, the abstract syntax becomes inadequate for OWL Full,
which needs all the official OWL RDF/XML exchange syntax expressivity.
2.7
Process specification languages
This category includes languages with specific constructs to model processes and, in particular,
the behavioural knowledge. The behavioural knowledge may involve the rules, strategies, and policies
of a business, as well as the resources available.
Traditionally, ontology languages have not addressed process modelling. Therefore, here we
analyse a few representative languages, to identify relevant modelling constructors.
•
•
Some formalisms for process modelling
Process Algebras,
Pi Calculus,
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 40 / 244
IP- Project
ATHENA -Project
Document
•
•
•
•
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
PSL,
Petri Nets
OWL-S,
BPEL
2.7.1
Process algebras
An algebra is a mathematical structure with a set of values and a set of operations on the values.
These operations may enjoy algebraic properties such as commutativity, associativity, idempotency,
and distributivity. In a typical process algebra, processes are values and parallel composition is
defined to be a commutative and associative operation on processes.
Process algebras are best described as a set of formalisms for modelling systems that allow for
mechanical mathematical reasoning with respect to a set of desired properties, be it equivalence,
absence of deadlocking or some safety property. It is usually the case that process algebras are used
to model concurrent systems and communicating systems.
•
•
•
Since process algebras represents a set of formalisms, they all share some features:
A formal language (an algebra), that provides the constructs for system descriptions
Equivalence relations, describing how to equate systems at one or more levels
A set of axioms, describing the ground terms which allow for the proving of validity of complex
systems.
Some process algebras introduce their own additional features. Some process algebras are: CCS
(The Calculus of Communicating Systems), PEPA (Performance Evaluating Process Algebra), CPS,
LOTOS, TIPP, IMC and many others, but generally speaking, the principles are the same throughout.
2.7.2
Pi-Calculus
π -calculus is a model of computation for concurrent systems.
The syntax of π-calculus lets you represent processes, parallel composition of processes,
synchronous communication between processes through channels, creation of fresh channels,
replication of processes, and non-determinism.
2.7.3
PSL (Process Specification Language)
PSL's primary role is not envisioned to be a process modeling language; it will be an interchange
language which would allow manufacturing applications to exchange discrete process data. For
example, an IDEF3-based application could use PSL to exchange process models with a Petri netbased application.
The goal of PSL is to create a process interchange language that is common to all manufacturing
applications, generic enough to be decoupled from any given application, and robust enough to be
able to represent the necessary process information for any given application.
The PSL project is currently in the process of merging with the Process Interchange Format (PIF)
effort. This new combined effort will bring together the representation of both business and
manufacturing process-related concepts into a single, unified process structure.
Process Specification Language (PSL) [51][52] is a first order logic ontology explicitely designed
for allowing (correct) interoperability among heterogenous software applications, that exchange
information as first-order sentences. It has undergone years of development in the business process
modeling arena, by defining concepts specifically regarding manufacturing processes and business
process. Recently, PSL has become an International Standard (ISO 18629).
PSL can model both “black box” processes, i.e., activities, and “white box” processes, i.e.,
complex activities, and allows formulae that explicitly quantify over and specify properties about
complex activities. The latter aspect, not shared by several other formalisms, makes it possible to
express in an explicit manner broad variety of properties and constraints on composite activities.
PSL is constituted by (finite) set of first order logic theories defining concepts (i.e., relations and
functions) needed to formally describe process and its properties (e.g., temporal constraints, activity
occurrences, etc.): they are defined starting from primitive ones, whose meaning is assumed in the
ontology. The definitions are specified as set of axioms expressed using the Knowledge Interchange
Format, KIF (see Section 2.4.1). PSL is extensible, in the sense that other theories can be created in
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 41 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
order to define other concepts: of course, the newly added theories must be consistent with the core
theories. Among the latter, Tpslcore defines basic ontological concepts, such as activities, activity
occurrences, timepoints, and objects that participate in activities. Additional core theories (see
) capture the basic
intuitions for the composition of activities, and the relationship between the occurrence of complex
activity and occurrences of its subactivities. Among those, it is worthwhile to mention the following
ones. Tocctree characterizes an occurrence tree, i.e., a partially ordered set of activity occurrences5.
Tdisc_state defines the notion of fluents (state), which are changed only by the occurrence of
activities. In addition, activities have preconditions (fluents that must hold before an occurrence) and
effects (fluents that always hold after an occurrence). Tcomplex characterizes the relationship between
the occurrence of complex activity and occurrences of its subactivities: an occurrence of complex
activities corresponds to an occurrence tree, i.e., a partially ordered set of occurrences of subactivities.
Finally, Tactocc captures the concepts related to occurrences of complex activities, and, in particular,
activities trees and their relations with occurrences trees (activities trees are part of occurrence trees).
5
Occurrence trees are isomorphic to the situation trees that are models of the axioms for Situation
Calculus: from this PSL can be considered as a dialect of Situation Calculus.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 42 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
illustrate (part of) the
lexicon of PSL and its intuitive meaning. Most of the terms are primitive fluents, with the following
exceptions: successor (a, s) is primitive function, poss(a, s), root_occ(o) and leaf_occ(s, o) are defined
in their respective theory (as KIF axiom). For example, the axiom capturing poss(a, s) is:
(forall (?a ?s) (iff (poss ?a ?s)
(legal (successor ?a ?s))))
It states that it is possible to execute an activity a after activity occurrence s if and only if the
successor occurrence of the activity a is legal. Note that legal(·) and successor(·) are primitive
concepts.
As far as its semantics, PSL has a model-theoretic semantics, based on trees that represent
possible sequences of (atomic) activities that might occur in an execution of an application. The
meaning of terms in the ontology is characterized by models for first-order logic. Indeed, the model
theory of PSL provides rigorous abstract mathematical characterization of the semantics of the
terminology of PSL. This characterization defines the meanings of terms with respect to some set of
intended interpretations represented as class of mathematical structures. Furthermore, for each theory
in PSL, there are theorems that prove that every intended interpretation is model of the theory, and
every model of the theory is isomorphic to some intended interpretation.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 43 / 244
IP- Project
ATHENA -Project
Document
Figure 2.
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Primitive Lexicon of PSL
Therefore, PSL has first-order axiomatization of the class of models, and classes in the ontology
arise from classification of the models with respect to invariants (properties of the models preserved by
isomorphism). Note that PSL semantics is based on the notion of tree, therefore, it is second order.
However, because of the assumption that processes exchange only first order sentences, PSL’s
syntax is first order. This implies that PSL cannot express rechability properties (i.e., after activity
occurrence a, eventually activity b occurs), since second order formula is needed.
The following example, taken from [51], illustrates some sentences in PSL.
Example:
∀(x, o) occurrence_of(o, drop(x)) ⊃ prior(fragile(x),o) ∧ holds(broken(x),o)
Intuitively, this formula states that if the object x is fragile, (i.e., fragile(x) is true immediately before
activity drop(x) occurs) then x will break when dropped (i.e., broken(x) is true immediately after activity
drop(x) occurs). 6
∀(x, o) occurence_of(o, make(x)) ⊃ (∃ o1, o2, o3) occurrence_of (o1 ,cut(x))
∧ occurrence_of (o2, punch(x)) ∧ occurence_of (o3, paint(x))
∧ subactivity_occurrence(o1,o) ∧ subactivity_occurrence(o2,o)
∧ subactivity_occurrence(o3,o)
∧ min_precedes(leaf_occ(o1), root_occ(o3),make(x))
∧ min_precedes(leaf_occ(o2), root_occ(o3),make(x))
Intuitively, this sentence states that in order to make the frame (activity make(x)), the cutting
(activity cut(x)) and the punching (activity punch(x)) should be done in parallel, before doing the
painting (activity paint(x)). Specifically, if o is the occurrence of activity make(x), then there exists o1,o2
and o3 which are occurrences of cut(·), punch(·)and paint(·), respectively, and which are subactivities
of o. There is partial ordering constraint between o1,o2 and o3: it is imposed that the last atomic
subactivities of o1 and o2 take place before the firts atomic subactivity of o3; the parallelism constraint
is captured by imposing no ordering constraint on the occurrences of subactivities of o1 and o2.
6
The frame problem is implicitly solved by the semantics of holds.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 44 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Finally, note that here we are implicitely assuming that the activities are complex, i.e., they are
constituted by certain number of subactivities. If this is not the case, i.e., o1 and o2 are primitive7, the
fluents min_precedes have o1 and o2 as first component (instead of their roots), and the conjunction
primitive(o1) ∧ primitive(o2)8 is added to the above sentence.
2.7.4
Petri Nets
A Petri net is a mathematical representation of discrete distributed systems. Petri nets were
defined in the 1960s by Carl Adam Petri. Because of their ability to express concurrent events, they
generalize automata theory.
It consists of places, transitions, and arcs that connect them. Input arcs connect places with
transitions, while output arcs start at a transition and end at a place. There are other types of arcs, e.g.
inhibitor arcs. Places can contain tokens; the current state of the modeled system (the marking) is
given by the number (and type if the tokens are distinguishable) of tokens in each place. Transitions
are active components. They model activities which can occur (the transition fires), thus changing the
state of the system (the marking of the Petri net). Transitions are only allowed to fire if they are
enabled, which means that all the preconditions for the activity must be fulfilled (there are enough
tokens available in the input places). When the transition fires, it removes tokens from its input places
and adds some at all of its output places. The number of tokens removed / added depends on the
cardinality of each arc. The interactive firing of transitions in subsequent markings is called token game
Petri nets are a promising tool for describing and studying systems that are characterized as being
concurrent, asynchronous, distributed, parallel, nondeterministic, and/or stochastic. As a graphical tool,
Petri nets can be used as a visual-communication aid similar to flow charts, block diagrams, and
networks. In addition, tokens are used in these nets to simulate the dynamic and concurrent activities
of systems. As a mathematical tool, it is possible to set up state equations, algebraic equations, and
other mathematical models governing the behaviour of systems.
In its most basic form, tokens in a Petri net are indistinguishable from each other. More complex
Petri nets add token colouring, activation time and hierarchy to the network.
Several important extensions to basic Petri nets exists in this sense.
2.7.5
OWLS-S
OWL-S is a OWL-based Web service ontology, for describing the properties and capabilities of
Web services in a computer-interpretable form.
OWL-S aims at facilitating the automation of Web service tasks, including automated Web service
discovery, execution, composition and interoperation.
The description of a Service is composed by 3 sections (Figure 3):
ServiceProfile, what the service does,
ServiceModel, how the service works,
ServiceGrounding, how to access the service.
Generally speaking, the ServiceProfile provides the information needed for discovering a service,
while, the ServiceModel and the ServiceGrounding provide information for an agent to make use of a
service.
ServiceProfile
The ServiceProfile gives the types of information needed by a service-seeking agent, to determine
whether the service meets its needs.
•
An OWL-S Profile describes a service as a function of three basic types of information:
what organization provides the service. Essentially this information consists of contact information
that refers to entity that provides the service.
7
Note that PSL makes a distinction between an atomic and a primitive activity: an activity is called
primitive if it has no subactivities; an activity is atomic if either primitive or it is the concurrent
aggregation of primitive activities.
8
The term primitive(.) is defined in the Subactivity theory that is not reported here.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 45 / 244
IP- Project
ATHENA -Project
Document
•
•
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
what function the service computes. The functional description of the service is expressed in
terms of the transformation produced by the service. Specifically, it specifies the inputs required
by the service and the outputs generated; furthermore, since a service may require external
conditions to be satisfied, and it has the effect of changing such conditions, the profile describes
the preconditions required by the service and the expected effects that result from the execution
of the service. For example, a selling service may require as a precondition a valid credit card
and as input the credit card number and expiration date. As output it generates a receipt, and as
effect the card is charged.
a host of features that specify characteristics of the service, such as: the category of the service,
for instance the category within the UNSPSC classification system; the quality rating of the
service. The last type of information is an unbounded list of service parameters that ca contain
any type of information.
ServiceModel, it describes what happens when the service is carried out. To give a detailed
perspective on how a service operates, it can be viewed as a process. OWL-S defines a subclass of
ServiceModel, the ProcessModel. It adopts two views of a process. First, a process produces a data
transformation from a set of inputs to a set of outputs. Second, a process produces a transition in the
world from one state to another. This transition is described by the preconditions and effects of the
process. Furthermore the ProcessModel identifies three types of processes: atomic, simple and
composite. Atomic processes are directly invocable; they have no sub-processes, and execute in a
single step, from the perspective of the service requester. For each atomic process there must be
provided a grounding. Simple processes are not invocable and are not associated with a grounding,
but, like atomic processes, they are conceived of as having single-step executions. Simple process are
used as elements of abstraction. Composite processes are decomposable into other (non-composite
or composite) processes; there decomposition can be specified by using control constructs such as
SEQUENCE and IF-THEN-ELSE. Such decomposition also shows how the various inputs and outputs
of the process are accepted by particular sub-processes.
ServiceGrounding, it specifies a communication protocol, message formats, and other servicespecific details, such as port numbers used in contacting the service. A grounding can be thought as a
mapping from an abstract to a concrete specification of those service description elements that are
required for interacting with the service.
Figure 3.
2.7.6
The top level of the Service ontology
BPEL
BPEL4WS defines a model and a grammar for describing the behavior of a business process
based on interactions between the process and its partners.
BPEL provides an XML notation and semantics for specifying business process behavior based
on Web Services. A BPEL4WS process is defined in terms of its interactions with partners. A partner
may provide services to the process, require services from the process, or participate in a two-way
interaction with the process. Thus BPEL orchestrates Web Services by specifying the order in which it
is meaningful to call a collection of services, and assigns responsibilities for each of the services to
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 46 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
partners. It can be used to specify both the public interfaces for the partners and the description of the
executable process.
The interaction with each partner occurs through Web Service interfaces, and the structure of the
relationship at the interface level is encapsulated in what we call a partner link. The BPEL4WS process
defines how multiple service interactions with these partners are coordinated to achieve a business
goal, as well as the state and the logic necessary for this coordination. BPEL4WS also introduces
systematic mechanisms for dealing with business exceptions and processing faults. Finally, BPEL4WS
introduces a mechanism to define how individual or composite activities within a process are to be
compensated in cases where exceptions occur or a partner requests reversal.
BPEL4WS is layered on top of several XML specifications: WSDL 1.1, XML Schema 1.0, and
XPath1.0. WSDL messages and XML Schema type definitions provide the data model use by
BPEL4WS processes. XPath provides support for data manipulation. All external
resources and partners are represented as WSDL services. BPEL4WS provides extensibility to
accommodate future versions of these standards, specifically the XPath and related standards used in
XML computation.
2.8
A detailed description of some languages
Some of the languages previously presented, are here described in a more detailed way in order
to have a deeper insight on some of them. For this reason, some criteria have been identified. In
particular, these criteria refer to the components usually used to describe domain knowledge:
•
Concepts
•
Attributes/Relations
•
Functions
•
Axioms
•
Instances
A complete description of the synoptic table is given below.
Synoptic table
Concepts
To enhance the guidance in the ontology building
Predefined categories:
Constructors:
Definition of concepts by using logical operators, by enumerating all the
individuals that are instances of the concept or by listing (and constraining) its properties
Intersection
AND:
Union (Disjoint OR: union of disjoint concepts)
OR :
Complement
NOT:
List of the instances
Enumeration:
Constraint over one or more properties of the concept
Restriction:
Natural language description and other metadata indicating the
Documentation:
author, the date of creation of the concept, the documental
sources for the definition of the concept
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
050404_ATHENA_DA31_PartA_V10.doc
Attributes whose value may be different for each instance of the
concept.
Attributes whose value must be the same for all instances of the
concept.
Attributes with the same name and different characteristics for
different concepts
To assign a value to the attribute in case there is no explicit value
defined for it.
To specify and constrain the type of the attribute (basic type)
To specify and constrain the cardinality of the attribute
Natural language description and other metadata concerning the
attribute
CONFIDENTIAL
Page 47 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Relations (Domain Relations)
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
The term used to refer the relation
To specify and constrain the cardinality of the relation
Indicate which is the domain concept for the attribute
Indicate the range in which the attribute assumes values
Natural language description and other metadata concerning the
relation
Relations with entities that play a specific role (predefined) in the
correct definition of the concept, within the business domain.
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similarity:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
Assert that a concept is a specialization of the other (i.e., the
instances set of the firs concept is a subset of the instances set of
second concept)
Assert that different descriptions represent the same concept
(i.e., the concepts instances sets concide)
Assert that the concepts represent similar entities
Assert that a concept represents a component of another concept
Assert that the concepts instances sets have no intersection
The possibility of expressing axioms on concepts by using FOL
(higher-OL) formulas
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Inverse*:
Reflexive*:
Symmetric*:
Transitive*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
Assert that an attribute is a specialization of another attribute (i.e.,
the first attribute can be applied whenever the second one can be
applied
Assert that different labels denote the same attribute
Assert the existence of an inverse relation
Assert that (x,x) in R
Assert that if (x,y) in R then also (y,x) in R
Assert that if (x,y) in R and (y,z) in R then also (x,z) in R
Assert that the attribute can assume a unique value for each
object
Assert that, for each attribute value can exist a unique object
having that value for the attribute
The possibility of expressing axioms on attributes and relations by
using FOL (higher-OL) formulas
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
The possibility of defining a meta-level, meta-meta-level, etc.
The creation of instances of concepts
The assertion of a relation between instances
Assert that different labels denote the same individual
Comments
This section will contain additional notes on the specific language.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 48 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Process Specific Section
Control flow:
Message flow:
State/transition
Activation/termination
criteria
Structural profile
Description of the ordering of execution of the processes
(e.g.,sequencing, fork, iterations)
Description of the interaction between two processes, in terms of
the exchanged messages
Description of the “states” of an object and the transitions that
determine the objects change of state. An object is said to be in a
“state” if it satisfies some condition
Description of the conditions for activation/termination of a
process (e.g., pre and post-conditions).
Description of the static aspects of a process, e.g., where and by
whom activities are performed, the involved resources, average
time, cost etc
*Only applicable to relations, not to attributes.
Topic Maps
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
050404_ATHENA_DA31_PartA_V10.doc
Topic
In Topic Maps, the topic (or topic link) is the fundamental
construct to talk about the universe of Discourse, which is
supposed to be composed of subjects. A subject is whatever can
be asserted about, be it abstract concept or real-world object.
Subjects are represented by Topics. Semantics of subjects
should be defined by links to addressable resources (available
over the internet) called occurrences, and by relationships
established between topics themselves through associations.
This is actually only one way to see the entire question. Actually,
a Topic Map is meant to talk about addressable resource
available over a network. Subjects are thus a kind of conceptual
metadata that can be attached to network resources by means of
topic links.
An important thing to be noticed is that any subject can be
represented by a Topic. In particular, topics are used to represent
“types” for almost every constructs available in the Topic Maps
language. A type, in a sense, resembles the concept of class:
other topics may relate to a type and they are considered to be
“instances” of the type.
Note that there is no syntactic mechanism to prevent overlapping
between the concept of individual and that of class.
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
CONFIDENTIAL
Page 49 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
Topic characteristic; facet, facet value
Notice that topic characteristics refer to topics, and are
constrained to a fixed set of characteristics, particularly names,
occurrences and roles. Facets, on the other hand, refer to
subjects, and are seen as a way to express properties of
information objects external of the topic map from within the topic
map itself.
Topic characteristic; facet, facet value
No
Not Supported
Facet type; facet value type
Not Supported
Not Supported
Relations (Domain Relations)
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
Association
Associations assert relationships between topics. It is important to
notice that associations act on topics as individuals. The
existence of an associations between two topic types does not
mean that an instance of the association holds or may hold
between their instances.
In a sense, associations are relationships between individuals. As
such, the concepts of cardinality, domain and range do not apply
here.
The “scope” construct is instead used to limit the validity of
associations to topics within certain set of themes.
Not Supported
Not Supported
Not Supported
Not Supported
No
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
050404_ATHENA_DA31_PartA_V10.doc
InstanceOf
The new draft for the standard also considers explicitly the
specification of a supertype-subtype relationship through an
association having particular syntax.
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
Notice that a Constraint Language is currently being defined as
part of the new version of the Topic Maps standard. This
language, called TMCL, is essentially a schema language for
topic maps. However, it seems from the current drafts that it will
comprise a sublanguage TCML-Rule, with constructs to specify
assertions on topic maps through variables, predicates and
universal quantification.
CONFIDENTIAL
Page 50 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Inverse*:
Reflexive*:
Symmetric*:
Transitive*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
Not supported
Note that every association may have an association type, which
is a topic item describing the association. This is asserted through
an InstanceOf element Belonging to a type may be seen as a
form of ISA, but it doesn’t relate two associations directly.
There is no explicit mechanism to assert an association between
two associations. To express it, associations must be reified.
Not Supported
Not Supported
Not Supported
All associations in topic maps are intrinsically symmetric as they
don’t have an orientation. However, association roles create an
asymmetry.
Not supported
Not supported
Not supported.
In the draft for the new standard, a topic name, occurrence, or
association item may represents a unique topic characteristic
under certain syntactical rules.
Not supported (but see the correspondent note for properties on
concepts)
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
050404_ATHENA_DA31_PartA_V10.doc
Topics, that constitute the base objects in topic maps, may
represent a single individual concept (instance), but are also used
to express types of concepts and associations. Types can be
arranged in hierarchies only through user defined associations,
and no concept of inheritance is supported. A form of reification
allows talking about facts represent in topic maps. For example,
associations may be reified to express properties of an
association as a whole. However, this reification mechanism has
some limitations and does not seem to allow the expression of
generalized properties at the meta-level. Indeed, while it is
certainly possible to express properties of specific associations
through reification, it does not seem possible to express
properties or constraints over the concept of association itself, or
over the concept of topic or any other construct involved in topic
maps.
InstanceOf
Note that the data model of topic maps comprehends the concept
of occurrence. Anyway, as from its definition, an occurrence of a
topic is not an instance of the topic. It is a representation of
relationship between a subject and an information resource
(possibly external to the topic map itself) that is relevant to the
subject in some way.
Association
Not Supported
CONFIDENTIAL
Page 51 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Comments
Topic Maps and their syntax(es) are described in the ISO/IEC standard ISO/IEC 13250. The most
recent version of this standard dates to 2002. However a new version is currently being prepared.
This new version contains several improvements and additions to the original concepts behind
Topic Maps and heads toward a more formalized specification of their nature and properties. As
this last version has still the nature of a draft, we refer to the syntax described in the 2002
document. However, were interesting, we make some explicit reference to the new ideas and
proposals being discussed in the new draft.
Standard ISO/IEC 13250:2002 allows two different syntaxes for Topic Maps. The first is based on
the SGML HyTime language, the other one uses XML. As this last syntax is likely to become the
most used and receives grater attention in the new proposals for the standard, we refer here to this
syntax (Also called XTM). All the grammar keyword used in this table refer to names of XML
elements or attributes.
*Only applicable to relations, not to attributes.
UML
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
Class
Only as multiple inheritance.
Not Supported
Not Supported
Enumeration
Not Supported
Comment
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
Attributename:attributetype=defaultvlaue
Not Supported
Yes
Specified as value for the attribute in the class specification
Specified as type for the attribute in the class specification
Not Supported
Comment
Relations (Domain Relations)
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
050404_ATHENA_DA31_PartA_V10.doc
Association; AssociationClass
An association specifies a relationship between classes
cardinality constraints on Association ends
Domain and range specification for associations are specified
directly by the link between classes. In UML, relations
(associations) cannot exist as independent elements, without
being attached to other constructs such as classes. This also
means that each association is unique. Even if two associations
have the same name, hey are connected to different classes and
thus they are considered to be different. Thus domain and range
for an association both contain one class and are bound to the
classes that the association links together.
See above
Comment
There are no standard associations defined in UML. Other kind of
relationships may be specified between elements in a UML
through constructs different from Association. For example, it is
possible to specify dependencies. Several standard such
relationships may be expressed using stereotypes. Anyway, this
constructs have a different meaning and are less similar to the
CONFIDENTIAL
Page 52 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
standard concept of relation as intended in most ontological
languages.
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
Generalization
Not Supported
Not Supported
Decomposition/Aggregation
Disjoint (Applies to a set of subclasses of a class)
OCL statements
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Inverse*:
Reflexive*:
Symmetric*:
Transitive*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
Generalization of an Association
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
isUnique attribute of Association Ends
isUnique attribute of Association Ends
OCL statements
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
050404_ATHENA_DA31_PartA_V10.doc
UML is organized in a four layer metamodeling architecture, such
that constructs at each level are defined in the level immediately
above. There is clean separations between the levels, and an
UML user model, cannot be used to manipulate itself. UML
provides some extension mechanisms that allow to extend the
language and tailor it to specific modelling needs. Furthermore,
MOF, the meta-meta model used to describe the UML
metamodel, shares many similarities with the metamodel itself,
so that it can be mapped to (a subset of) UML. In other words,
UML could be used to model itself. This features, however, does
not imply actual reification capabilities of the language or
coexistence of different instantiation levels.
InstanceSpecification
An InstanceSpecification represent a instance of a class (or other
classifier). Instances must refer to a class (or classifier). It is not
possible to define instances that don’t belong to any class.
Furthermore, instances may be only partially specified. In this
case some of the values for their slots may assume defaults or
can be computed or may remain unspecified.
Instances of Associations may be shown through
InstanceSpecifications. However, an association between
instances may only exist as instance of an association between
the corresponding classes. Specification of associations that only
hold between individual instances is not supported.
Not Supported
CONFIDENTIAL
Page 53 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Comments
The current specification for UML is the 1.5 version. However, a new specification (2.0) has already
been accepted by the OMG and is currently undergoing an initial maintenance revision. We refer
here to this new version.
UML comprises a fairly rich constraint language (OCL) allows to express constraints almost
everywhere. It’s thus important to notice once again that the keyword “Not Supported” used
throughout the synoptic table only means that the language doesn’t offer a construct to express
directly a certain fact. Several properties for which there is no explicit syntax might be expressed
through OCL statements.
KIF
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
defrelation
The conceptualization behind KIF considers the UoD made of
objects, list of objects and set of objects. The most basic primitive
that may be used to model knowledge is the relation, which is a
set of lists of objects.
There is not any prebuilt concept as that of class.
and
or
not
Not Supported
Not Supported
Not supported
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
Not Supported
N/A
N/A
N/A
N/A
N/A
N/A
Relations (Domain Relations)
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
050404_ATHENA_DA31_PartA_V10.doc
Defrelation, deffunction
There is no syntactic restriction on the number of arguments to a
function (relation). The same function (relation) can be applied to
any finite number of arguments. Arity restrictions are treated
semantically.
Ma questa è arity, ti ho chisto cardinality…
Not Supported (ma sei sicuro??)
Not Supported (ma sei sicuro??)
Not supported
No, though KIF defines several relations that allow to talk about
sets and lists of objects and about numbers.
CONFIDENTIAL
Page 54 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
Not Supported
<=>
Not supported
Not supported
Disjoint
All KIF Axioms
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Reflexive*:
Symmetric*:
Transitive*:
Inverse*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
Not supported
<=>
Not supported
Not supported
Not supported
Inverse
Not supported
Not supported
All KIF Axioms
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
In KIF it is possible to talk about KIF sentences using the quote
and the denotation keywords.
???? R(a), where R is a constant denoting a relation and a is
constant denoting an object.
????? R(a), where R is a constant denoting a relation and a is
constant denoting an object.
=
Comments
*Only applicable to relations, not to attributes.
F-Logic
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
050404_ATHENA_DA31_PartA_V10.doc
Classname[ list of typed attributes and methods]
Logical AND ∧
Logical OR ∨
Logical NOT ¬
Not supported
Not Supported
Not supported
CONFIDENTIAL
Page 55 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Attributes
Instance attribute:
Concept Name[ Attr ⇒ AttrType;
…
]
This definition defines a concept (a Class) with an attribute of
type AttrType.
The value of the attribute is not initially specified, and must be
specified by members. An analogue definition may be specified
for Attributes with multivalued (set) type.
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
Concept Name[ Attribute name → Attribute Value;
…
]
This definition defines a concept (a Class) with a non-inheritable
property Attr. A non-inheritable property is NOT inherited by
members of the class. It is a property of the class itself.
Yes
Not Supported
Concept Name[ Attribute name •→ Attribute Value;
…
]
This definition defines a concept (a Class) with an inheritable
property Attr. A inheritable property is inherited by all members of
the class, unless it is overwritten.
Allowed types are classes. Specifying (class1,class2) in a type
definition means that the attribute belongs to both class1 and
class2.
Attributes may be scalar or set valued. No explicit restriction on
cardinality.
Relations (Domain Relations)
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
Not Supported
F-logic does not support the concept of relation. Relations may be
expressed using methods of classes.
N/A
N/A
N/A
N/A
N/A
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
050404_ATHENA_DA31_PartA_V10.doc
Class2::Class1 means that Class2 is a subclass of Class1.
Not supported
Not supported
Not supported
Not supported
F-logic is a higher order logic. Axioms may be expressed in Flogic directly.
CONFIDENTIAL
Page 56 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Reflexive*:
Symmetric*:
Transitive*:
Inverse*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
Not supported
Not supported
N/A
N/A
N/A
N/A
Not supported
Not supported
See above
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
F-logic makes no distinction between instances, classes,
metaclasses etc.
A :Class1 means that A is an instance of Class1
N/A
Not Supported
Comments
*Only applicable to relations, not to attributes.
ONTOLINGUA
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
Thing, Class, Define-class
and
or
not
one-of
Not Supported
double quoted string inside a class definition.
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
:instance-slots, has-slot-value, has-slot-value-of-type, has-value
:class-slots
Not-supported
Apart from syntactic sugaring, Ontolingua defines slots as
relations, and relation definitions are global.
:constraints, :default-slot-values
slot-value-type
slot-cardinality
double-quoted string inside a class definition, Documentation
Relations (Domain Relations)
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
050404_ATHENA_DA31_PartA_V10.doc
define-relation
??
domain
range
Double-quoted string inside a relation definition, Documentation
Not Supported
CONFIDENTIAL
Page 57 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
(subclass-of C1 C2)
<= =>, iff-def:
Not supported
Class-partition, subclass-partition, exhaustive-subclass-partition
disjoint(?s1, ?s2)
All KIF Axioms
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Reflexive*:
Symmetric*:
Transitive*:
Inverse*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
(subrelation-of R1 R2)
Alias
Reflexive-relation
Symmetric-relation
Transitive-relation
inverse(?r)
One-to-one-relation
Not Supported
All KIF axioms
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
In KIF it is possible to talk about KIF sentences using the quote
operator.
Within an instance definition : Define-instance instance-name
(Class-name) …
In an axiom: (instance-of instance-name Class-name)
Not supported.
=
Comments
To enhance usability from community of users with diverse needs, the syntax of Ontolingua is quite
redundant, allowing to specify constraints and other properties in various forms. In particular, most
properties may be specified either as first order (KIF) sentences or with second-order relations
defined in the Frame Ontology. We have tried here to use only these second-order forms, which
are specific of Ontolingua. In this case, the use of this forms is intended in axioms or in definitional
forms, to state that a certain object participates to a certain class or relation defined in the Frameontology.
Where possible, we’ve also added the definitional lisp like form (one of define-class, definerelation,define-function, define-instance.
*Only applicable to relations, not to attributes.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 58 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
OIL
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
class-def
OIL allows to define classes. Furthermore, slot-constraints
that can appear in a class definition may be considered as
class definitions on their own. A slot constraint defines a
class by imposing constraint on how members of this
class can participate to a relation, i.e. a slot. A slotconstraint actually imposes a subclass constraint on the
class being defined with class-def.
AND
OR
NOT
one-of
slot-constraint + has-value, value-type.
documentation
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
050404_ATHENA_DA31_PartA_V10.doc
Not supported
An attribute definition is not directly supported, but slot
constraints may be used to define relations that act as
attributes for class instances. A slot-constraint may be
viewed as an attribute definition, as it constraints class
instances to be in certain relation with other class
instances. Usually, to allow a slot constraint to resemble
more closely an attribute as it is usually intended, other
constraint must be specified, like a functional constraint
that forces the attribute to have only one value.
Not supported.
Anyway, as the slot-constraint construct is very flexible, it
is possible to constraint a slot to have the same value for
each instance of a class.
No.
OIL does not have a native concept of scope of an
attribute. Slots may be restricted to apply only to some
classes using domain and range constraints, but in
principle any instance of any class may participate to a
relation (a slot). However, due to the possibility of
specifying slot constraints, some features related to
polymorphic treatment of attributes are quite easy to state.
For example, a slot constraint may have different range
depending of the class considered (e.g. a human and a
javaclass may both participate to the slot has-parent with
different range, meaning that parent of humans are
humans and parents of java-classes are java-classes)
Not supported
Value-type, has-value
Min-cardinality, max-cardinality, cardinality
Not supported
CONFIDENTIAL
Page 59 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Relations (Domain Relations)
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business Domain
relations:
Slot-def
Cardinality constraints may not be expressed directly on
the slot, but may be attached to classes that participate to
the relation through slot constraints.
domain
range
Documentation
Not Supported
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints expressed with
First or higher order logic
formulas:
subclass-of
equivalent
Not supported
Not supported
Disjoint
Not supported
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Reflexive*:
Symmetric*:
Transitive*:
Inverse*:
Unique:
Inverse unique:
Generic constraints expressed with
First or higher order logic
formulas:
Subslot-of
Not supported
Not supported
Properties symmetric
Properties transitive
Inverse
Not supported
Not supported
Not supported
Instances
Multiple instantiation layers:
Concept instance:
Relations between instances:
Equivalent:
050404_ATHENA_DA31_PartA_V10.doc
Not supported.
OIL essentially allows to make statements at two level,
the oject level (that of instances) and the meta-level (at
which the ontology is defined). There are two predefined
concepts (Top e Bottom), but its not possible to talk about
OIL constructs or statements.
What the OIL specifications call meta-meta-level or
container is actually a set of metadata about the ontology
specification.
Instance-of
related
Not supported
CONFIDENTIAL
Page 60 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Comments
As described earlier in this document, OIL is composed by fur nested layers of increasing
expressivity. Here we consider the language in its full expressivity (i.e, the Instance OIL layer, as
the most external layer, the Heavy OIL layer, has not yet been defined).
*Only applicable to relations, not to attributes.
Synoptic table: XML-Schema
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
050404_ATHENA_DA31_PartA_V10.doc
Element Declarations / Type Declarations
XML Schema allows to define classes of XML documents by
describing (and constraining) their structure and data types. An
XML schema document may be seen as a graph of information
items of various kind. In particular, it contains type definitions and
element and attribute declarations. Simple Type definitions allow
to define constraints on possible string values for attributes and
text-only elements. Complex Type definition allow to define a
content (children elements) and a set of attributes for an element
of that type. Type definition are arranged in a derivation
hierarchy, which is basically a ISA hierarchy.
Element and attribute declaration are used both in complex type
definitions and in a global scope and may be seen as
associations between names and types.
The type system of XML Schema has the aim of enabling to
express constraints that XML documents must satisfy in order to
be valid against a certain schema.
There is no easy correspondence between these syntactic
constructs and modelling primitives since no semantics is
whatsoever defined, neither informally, for them.
The type system, however, has many similarities with type
systems of object oriented programming languages. Complex
types are in a way similar to classes, that have named
“properties” both of atomic type (attributes and element with no
subelement children) and of complex type (elements with a
complex type).
This interpretation is not, however, expressed anywhere in the
specification, and different intended semantics could be
considered.
Not Supported
Union
Not Supported
Not Supported
Various Restriction mechanisms are allowed for type derivation.
Documentation; appinfo; annotation
(These are elements explicitly defined to maintain documentation.
In addition to these, the generic XML-style comment, <!—
comment -->, may be used)
CONFIDENTIAL
Page 61 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Attributes
Instance attribute:
<xsd:attribute name="attribute name" type="attribute type"
Default="default value"/>
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
Not Supported
Yes
Default (see above)
Type (see above)
1
Not Supported
Relations (Domain Relations)
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
XML Schema does not support user defined relations.
The only form of relation that may be considered for elements is
nesting.
Relations might be expressed for example by nesting of
elements, interposing elements representing relation names (i.e.
reifying relations to elements). This would mean, however, to
implicitly add some semantics to the language.
N/A
N/A
N/A
N/A
N/A
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Inverse*:
Reflexive*:
Symmetric*:
Transitive*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
050404_ATHENA_DA31_PartA_V10.doc
Not Supported
Not Supported
N/A
N/A
N/A
N/A
Not Supported
CONFIDENTIAL
Page 62 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
An XML schema document defines the structure of XML
documents that validate against is. It only contains element and
type definitions, while instances are contained in related XML
documents.
There is thus an explicit separation between the conceptual and
the instance layer.
See above.
N/A
Not Supported
Comments
XML Schema can hardly be considered as an ontology language. It has not been designed to
provide means to describe a conceptualization of the world, apart from XML documents. It has no
semantics and it does not allow to define any semantics for element or types. However, it has
some basic features that allow for the representation of structured knowledge.
*Only applicable to relations, not to attributes.
RDFS
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
rdf:Class
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
rdfs:comment
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
NOT EXPRESSIBLE
RDF(S) does not support a concept of attribute, in that properties
are only defined globally and there is not any concept of scope or
any way or restricting properties range based on a specific class.
In particular, there is no way to state that every instance of a
certain class must participate to a relation.
RDF triple having the class as subject and a resource as object
Note that this does not mean that each instance as a property of
this kind: only the class is in relation with the resource.
No
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
rdfs:comment
Relations
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
050404_ATHENA_DA31_PartA_V10.doc
NOT EXPRESSIBLE
rdfs:domain
rdfs:range
rdfs:comment
No
CONFIDENTIAL
Page 63 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
rdfs:subClassOf
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Inverse*:
Reflexive*:
Symmetric*:
Transitive*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
rdfs:subPropertyOf
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
NOT EXPRESSIBLE
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
RDFS allows full reification of the concepts it uses. Rdf allow to
talk about resources and properties (which in turn are resources).
Classes are themselves view as resources, and may be grouped
into classes etc.
rdf:type
RDF triple
Every RDF triple assets a property between two resources. In
particular, resources may be instances.
NOT EXPRESSIBLE
Comments
*Only applicable to relations, not to attributes.
OWL
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
050404_ATHENA_DA31_PartA_V10.doc
owl:Class, owl:ObjectProperty, owl:DatatypeProperty
owl:intersectionOf
owl:unionOf
owl:complementOf
owl:one of
owl:Restriction,owl:onProperty, owl:allValuesFrom,
owl:someValuesFrom, owl:hasValue, owl:minCardinality,
owl:maxCardinality, owl:cardinality
rdfs:comment
CONFIDENTIAL
Page 64 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
owl:DatatypeProperty
owl:DatatypeProperty (in the concept definition, restriction with
the owl:hasValue constraint)
in the concept definition, restriction with the owl:allValuesFrom
constraint
not supported
rdfs:range of the DatatypeProperty
in the concept definition, restriction with the owl:cardinality
constraint
rdfs:comment
Relations (Domain Relations)
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
owl:ObjectProperty
only in the definition of a concept, by a restriction
rdfs:domain
rdfs:range
rdfs:comment
not supported
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
rdfs:subPropertyOf
owl:equivalentClass (we have also owl:differentFrom)
not supported
not supported
owl:disjointWith
all DL formulas
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Reflexive*:
Symmetric*:
Transitive*:
Inverse*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
rdfs:subClassOf
owl:equivalentProperty
not supported
owl:SymmetricProperty
owl:TransitiveProperty
owl:inverseOf
owl:FunctionalProperty
owl:InverseFunctionalProperty
all DL formulas
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
050404_ATHENA_DA31_PartA_V10.doc
supported only in OWL Full
rdf:type ????
RDF triple (s,p,t)
(Nota: questa è relation instance, non relation between
instances…)
owl:sameAs
CONFIDENTIAL
Page 65 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Comments
*Only applicable to relations, not to attributes.
PSL
Concepts
Predefined categories:
ACTIVITY
Note: the model underlying PSL is designed to express behaviour
of processes. Thus top-level categories are activities, occurrence
of activities, objects and timepoints. These four concepts are
mutually disjoint. Activity occurrences may be considered as
instances of Activities. In particular, activities model abstract
(reusable) actions, while occurrences model instances of a
certain activity taking place during a certain period of time.
Timepoints and Objects exist per-se, and are not instantiated. We
thus report here three basic categories. In the following of this
section we consider only the construction of Activities, which are
the concept which are the only concepts used to describe
complex elements of the business domain. Note that the object
category models everything that is not an activity or a timepoint.
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
and
Not supported
Not supported
Not supported
Not supported
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
There is no way to express attributes of activities in PSL.
N/A
N/A
N/A
N/A
N/A
N/A
Relations
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
Domain relations:
050404_ATHENA_DA31_PartA_V10.doc
The Basic PSL language does not allow to create user-defined
relations.
New relations may be defined with KIF axioms as extensions of
the PSL ontology.
N/A
N/A
N/A
N/A
Several business-domain relations.
CONFIDENTIAL
Page 66 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
Not Supported
Not Supported
N/A
Subactivity
Activities are either related through the subactivity relation or
disjoint.
KIF axioms
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Inverse*:
Reflexive*:
Symmetric*:
Transitive*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
PSL does not support any predefined relation on relations,
because it does not allow to define relations directly. They may
be defined as extensions to the basic PSL ontology as KIF
axioms.
Instances
Multiple instantiation layers:
Concept instance:
Relations between instances:
Extensions to the PSL ontology may be defined with KIF axioms.
ACTIVITY_OCCURRENCE
The Basic PSL language does not allow to create user-defined
relations on instances. The PSL ontology New relations may be
defined with KIF axioms as extensions of the PSL ontology.
PSL-Core and already defined extensions provide several
business domain relations on instances. Most important ones are:
Equivalent:
Control Flow
Relation for control flow are defined in the “Ordering Relations over Activities”, the “Ordering
Relations over Complex Activities” and the “Nondeterministic-activity” extensions.
Poset-activity, Complex-poset-activity define activities which have a partially ordered set of
subactivities.
Initial-activity,final-activity allow to define starting and final activity of a complex sequence of
activities
next-activity, Subactivity-precedes, Before-start, before-end, after-start,after-end, meets, starts,
finishes, during, overlaps, equals, non-concurrence, follows, leq-expect, next-expect-activity, leqrequired,next-required-activity, mutually-occurring, start-synchronization, end-synchronization, fullsynchronization, non-deterministic-choice,xor define relations between subactivities that express
sequencing, partial or total overlapping (i.e. concurrency), synchronization etc.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 67 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
MessageFlow
Not Supported
State/Transition
State/transitional features of processes may be defined through the States Extension.
Basic concepts of this extension are:
Fluent – a fluent is a property of the world that can change as a result of an activity occuring.
State - a relation holding between an actvity and a occurrence of an activity
States Extension and other extensions define other concept to reason on states.
Activation/Termination criteria
PSL-core:
Relations beginof ,endof, is-occurring-at relate activity-occurrences to timepoints.
Structural Profile
Not Supported
Comments
PSL is not a general purpose Ontology language. Rather, it has been designed as a language to
exchange information about processes and their behaviour. It is based on KIF, and uses this
language to define a basic ontology of concepts which may be used to describe processes and
their behaviour.
In this regard, it may be compared to efforts like Ontolingua, that define a basic ontology to model
concepts in a frame based way. Similarly to Ontolingua, PSL defines some basic concepts that act
as modeling primitives for the given domain (that of processes).
Differently from Ontolingua, PSL does not introduce any definitional form, and adheres only to the
syntax of KIF.
PSL descriptions are composed of KIF sentences that use the basic concepts defined by PSL-Core
and Extensions.
*Only applicable to relations, not to attributes.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 68 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
BPEL
Concepts
Predefined categories:
Constructors:
AND:
OR :
NOT:
Enumeration:
Restriction:
Documentation:
Process
BPEL allows to define processes and their behaviors. These
constitute the basic conceptual element expressible through its
syntax.
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
xml comment
Attributes
Instance attribute:
Concept attribute:
Polymorphic:
Default slot value:
Type:
Cardinality:
Documentation:
Variables
Variables correspond, in a sense, to the concept of attribute of
other representation languages. They provide the means for
holding messages that constitute the state of a business process.
The messages held are often those that have been received from
partners or are to be sent to partners. Variables can also hold
data that are needed for holding state related to the process and
never exchanged with partners.
Anyway, variables in BPEL are very similar to variables in most
executable programming languages and thus they exhibit several
differences with attributes as they are usually intended. For
example, they obey to lexical scoping rules, so that the same
variable name can be used to refer to different variables in the
body of the same process.
Global variables belong to the process during its entire lifetime,
while variables that are local to a scope may
Not Supported
Yes
Yes
Variables can be initialized with values that are then used by all
the instances of the process.
MessageType, type, element (attributes)
N/A
Xml comment
Relations
Relation name:
Cardinality:
Domain:
Range:
Documentation:
Predefined Business
050404_ATHENA_DA31_PartA_V10.doc
Not Supported
BPEL does not allow user defined relations between processes. ,
but it allow to specify two different business domain specific
relationships: Partner and PartnerLink (see below).
Partner and PartnerLink express relationships between
processes. Each instance of a processes must participate to
relation with exactly one other instance of the other process, so
it’s not possible to specify cardinality constraints.
Each PartnerLink is unique and it’s not possible to specify
partnerlinks or Partner relationships that apply to different couples
or groups of processes.
Domain and range are fixed and correspond to the processes
participating in a PartnerLink.
See the note for Domain.
Xml comment
The PartnerLink relation represents a conversational relationship
CONFIDENTIAL
Page 69 / 244
IP- Project
ATHENA -Project
Document
Domain relations:
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
between exactly two processes.
The Partner relation represent a Partnership between two
processes. A Partnership implies one or more PartnerLinks.
Properties of Concepts (Axioms on Concepts)
Predefined Relations:
ISA:
Equivalent:
Similar:
Part Of:
Disjoint:
Generic constraints
expressed with First or
higher order logic formulas:
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
Not Supported
Properties of Attributes/Relations (Axioms on
Attributes/Relations)
Predefined Relations:
ISA:
Equivalent:
Inverse*:
Reflexive*:
Symmetric*:
Transitive*:
Unique:
Inverse unique:
Generic constraints
expressed with First or
higher order logic formulas:
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Instances
Multiple instantiation layers:
Concept instance:
Relations between
instances:
Equivalent:
050404_ATHENA_DA31_PartA_V10.doc
No
Not Supported
The BPEL language is meant to describe processes. Instances of
Processes are actual process executions. BPEL does not allow
any mechanism to talk about specific executions of a certain
process.
N/A
Not expressible
CONFIDENTIAL
Page 70 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Control Flow
BPEL allows to express the behavior of each process as a set of activities. Activities describe how
a business process is created by composing the basic activities it performs into structures that
express the control patterns, data flow, handling of faults and external events, and coordination of
message exchanges between process instances involved in a business protocol. The state of a
process is maintained explicitly by variables, that are manipulated by activities pretty much as in a
normal programming language. WS-BPEL variables can either hold a WSDL message or an
arbitrary XML structure defined by a schema. The language features a set of basic activities and
constructs to build structured activities. Structured activities both allow to specify in-process
operation flow (choices, loops, recursion) and to coordinate spawning and execution of concurrent
processes. It also allow to determine the behavior of processes depending on non-deterministic
conditions like exceptions and external events. Ordinary sequential control between activities is
provided by sequence, switch, and while. Concurrency and synchronization between activities is
provided by flow. Nondeterministic choice based on external events is provided by pick.
The <variables> section of a process defines the data variables used by the process, providing
their definitions in terms of WSDL message types, XML Schema simple types, or XML Schema
elements.
The <sequence> construct allows you to define a collection of activities to be performed
sequentially in lexical order. The <switch> construct allows to select exactly one branch of activity
from a set of choices. The <while> construct allows you to indicate that an activity is to be
repeated until a certain success criteria has been met. The <scope> construct allows you to define
a nested activity with its own associated variables, fault handlers, and compensation handler.
The <pick> construct allows to block and wait for a suitable message to arrive or for a
time-out alarm to go off. When one of these triggers occurs, the associated activity is
performed and the pick completes.
The <flow> construct provides concurrency and synchronization. A flow activity creates a set of
concurrent activities directly nested within it. It further enables expression of synchronization
dependencies between activities that are
nested directly or indirectly within it. The <link> construct is used to express these
synchronization dependencies. If activity X is the target of a link that has activity Y as the source, X
has a synchronization dependency on Y. Every activity that is the target of a link has an implicit or
explicit joinCondition attribute associated with it. If an activity that is ready to start in this sense has
incoming links, then it does not start until the status of all its incoming links has been determined
and the (implicit or explicit) join condition associated with the activity has been evaluated. If the join
condition evaluates to false, a standard bpws:joinFailure fault is thrown, otherwise the activity is
started. In general, multiple target activities will be enabled based on the completion of an activity
with multiple outgoing links; because of this, such an activity is often called a fork activity.
MessageFlow
A business process provides services to its partners through receive activities. A receive activity is
a basic activity that specifies the partner link it expects to receive from, and the port type and
operation that it expects the partner to invoke. Receive activities play a fundamental role in the
lifecycle of a business process. The only way to instantiate a business process in BPEL4WS is to
annotate a receive activity with the createInstance attribute set to "yes".
Note that receive is a blocking activity in the sense that it will not complete until a matching
message is received by the process instance.
Invoking an operation on a web service provided by a partner is also a basic activity. Such an
operation can be a synchronous request/response or an asynchronous one-way operation.
BPEL4WS uses the same basic syntax for both with some additional options for the synchronous
case. In particular, the <invoke> construct is used for both kind of invocations.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 71 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
The <reply> construct allows the business process to send responses in reply to messages
that were received through a <receive>. Such responses are only meaningful for synchronous
interactions. An asynchronous response is always sent by invoking the corresponding one-way
operation on the partner link.
The combination of a <receive> and a <reply> forms a request-response operation on the WSDL
portType for the process.
Messages exchanged by these activities are defined through <properties> and stored into
variables.
State/Transition
BPEL4WS business processes represent stateful long-running interactions in which each
interaction has a beginning, defined behavior during its lifetime, and an end. The state involved
consists of messages received and sent as well as other relevant data such as time-out values.
The maintenance of the state of a business process requires the use of state variables, which are
called variables in BPEL4WS. Furthermore, the data from the state needs to be extracted and
combined in interesting ways to control the behavior of the process, which requires data
expressions. Finally, state update requires a notion of assignment. BPEL4WS provides these
features for XML data types and WSDL message types.
The <variables> section of a process definition declares the data variables used by the process,
providing their definitions in terms of WSDL message types, XML Schema simple types, or XML
Schema elements.
Activation/Termination criteria
The only way to instantiate a business process in BPEL4WS is to annotate a receive activity with a
createInstance attribute set to "yes", (see above, Message Flow). When a
message is received by such an activity, an instance of the business process is created if it
does not already exist.
A business process instance is terminated in one of the following ways:
- When the activity that defines the behavior of the process as a whole completes. In this
case the termination is normal.
- When a fault reaches the process scope, and is either handled or not handled. In this
case the termination is considered abnormal even if the fault is handled and the fault
handler does not rethrow any fault. A compensation handler is never installed for a
scope that terminates abnormally.
- When a process instance is explicitly terminated by a terminate activity. In this case the
termination is abnormal.
- If a compensation handler is specified for the business process as a whole, a business process
instance can be compensated after normal completion by platform-specific means.
Structural Profile
In BPEL4WS, processes are defined through the <process> construct. This element contains
several other elements that allow to specify both structural properties and dynamic behaviour
properties of the process.
In particular, the <partnerLinks> and <partners> subelements allow to specify relationships with
other process in the term of roles, port types and other features. The <variables> section allows to
declare variables that are used to maintain state information. The <correlationSets> section allows
to specify named groups of properties that serve to define a way of identifying an application-level
conversation within a business protocol instance.
The <faultHandlers>, <compensationHandler> and <eventHandlers> constructs are related to the
management of exceptions and events.
The explicit behaviour of the process is modeled through an activity or structured activity.
Comments
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 72 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
*Only applicable to relations, not to attributes.
2.9
Conclusions
This section has reported a survey of the most relevant languages for modelling ontologies. The
languages that have been considered are not only languages usually accepted by the ontology
community. This is because, the ontology research field is still in its infancy and requires to be
consolidated. The problem of identifying what can be properly considered as an ontology with respect
to other repositories of abstract models, such as: a thesaurus, a glossary, a data dictionary, a
knowledge base is still debated. We restricted our analysis, adopting the position that requires for an
ontology language a formal basis, and some reasoning techniques associated to it.
•
•
•
•
•
We identified the following families of languages:
Diagrammatic languages
Frame-oriented languages
Logic-based languages
Web-oriented languages
Process-oriented languages
Some of the identified languages have been analyzed in a more detailed way, using a set of
predefined criteria, such as the basic constructs to define: concepts, attributes, relations, instances,
formal properties of attributes and relations, possible restrictions (e.g., on domain/range, on
multiplicity) over them.
In the work of the A3 Project, we decided to adhere to the OWL proposal, but introducing some
enhancements due to its lack of domain specificity for the business domain.
•
•
•
The three main features that we would like to find in an ontology modelling language are:
formal basis, and availability of inference engines capable of reasoning over ontology content;
business-oriented constructs, to ease the construction of business ontologies (business domain
specificity)
expressive power, sufficient to model some characteristics related to process ontologies (e.g.,
precedence relation, conditionals to represent pre- and post-conditions).
None of the analysed languages presents at the same time the three above features. For this reason,
to fill this gap, we propose in Athena to use OPAL (Object, Process, Actor modelling Language), which
is the ontology modelling method based on OWL and enriched with specific constructs. The
description of OPAL is one of the objectives of the document D.A3.1b.
2.10 References
[1]
J.F. Allen, A.M. Frisch. What's in a semantic network? Proceedings of the 20th conference on
Association for Computational Linguistics, Toronto, Ontario, Canada, 1982
[2]
Artale, E. Franconi, F. Wolter, and M. Zakharyaschev. A temporal description logic for
reasoning over conceptual schemas and queries. Proc. of the 8th European Conference on
Logics in Artificial Intelligence (JELIA-2002), 2002.
[3]
A. Artale, E. Franconi, and F. Mandreoli. Description logics for modelling dynamic information.
Logics for Emerging Applications of Databases (J. Chomicki, R. van der Meyden, and G. Saake,
eds.), Springer-Verlag, 2003.
[4]
P. Auillans, P. Ossona de Mendez, P. Rosenstiehl, B. Vatant. A Formal Model for Topic Maps.
International Semantic Web Conference 2002: 69-83.
[5]
D. P. Ausubel. Educational psychology: A cognitive view. New York: Holt, Rinehart and
Winston, 1968.
[6]
F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi and P. F. Patel-Schneider. The
Description Logic Handbook: Theory, Implementation, and Applications. Cambridge University
Press, 2003.
[7]
F. Baader, I. Horrocks and U. Sattler. Description Logics: Handbook on Ontologies.
International Handbooks on Information Systems Springer 2004: pages 3-28, 2004.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 73 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
[8]
F. Baader, R. Molitor and S. Tobies. Tractable and Decidable Fragments of Conceptual Graphs.
In Proceedings of the Seventh International Conference on Conceptual Structures (ICCS'99),
LNCS 1640.
[9]
K.Backlawski et al. Extending UML to support Ontology Engineering for the semantics Web.
International Conference on UML, 2001.
[10]
J. Banerjee, W. Kim, H.J. Kim, and H. F. Korth. Semantics and Implementation of Schema
Evolution in Object-Oriented Databases. In Proc. of the ACM-SIGMOD Annual Conference (San
Francisco, CA): pages 311–322, May 1987.
[11]
T. Berners-Lee, J. Hendler, and O. Lassila. The Semantic Web, Scientific American, May 2001.
[12]
T. Berners Lee. Conceptual Graphs and the Semantic Web. Available on the web at
http://www.w3.org/DesignIssues/CG.html, 2001.
[13]
R.J. Brachman. On the epistemological status of semantic networks. In N.V. Findler, editor,
Associative Networks: The Representation and Use in Computers, pages 3-50. New York.
Academic Press Inc, 1979.
[14]
R.J. Brachman. What IS-A Is and Isn't: An Analysis of Taxonomic Links in Semantics
Networks. IEEE Computer, 16(10):pages 30-36, 1983.
[15]
D. Brickley and R. V. Guha. RDF Vocabulary Description Language 1.0: RDF Schema. W3C
Working Draft, 2003. Available at http://www.w3.org/TR/2003/WD-rdf-schema-20030123.
[16]
J. Broekstra, A. Kampman, F. van Harmelen. Sesame. In Spinning the Semantic Web, Fensel,
D., Hendler, J., Lieberman, H., Eds. , MIT Press, Cambridge, MA, 2003.
[17]
M. Buchheit, F. M. Donini, and A. Shaerf. Decidable reasoning in terminological knowledge
representation systems. Journal of Artificial Intelligence Research, Volume 1: 109-138, 1993.
[18]
H. M. Butler. Barriers to real world adoption of semantic web technologies. Technical Report,
Hewlett Packard, Filton Road Bristol BS34 8QZ UK, 2002.
[19]
A. Calì, D. Calvanese, G. De Giacomo, M. Lenzerini. A Formal Framework for Reasoning on
UML Class Diagrams. ISMIS 2002.
[20]
D. Calvanese, M. Lenzerini, D. Nardi. Description Logics for conceptual data modeling. In
Logics for Databases and Information Systems, Kluwer, 1998.
[21]
V. K. Chaudhri et al. Open Knowledge Base Connectivity 2.0.3 specification, April 1998.
[22]
V. K. Chaudhri, A. Farquhar, R. Fikes, P.D. Karp, and J. P. Rice. OKBC: A Foundation for
Knowledge Base Interoperability. In Proceedings of the National Conference on Artificial
Intelligence, 1998.
[23]
M. Chein, M. Mugnier. Conceptual Graphs: fundamental notions, Revue d’Intelligence
Artificielle, 6(4), pages 365-406, 1992
[24]
W. J. Clancey. Sowa's book review. Artificial Intelligence, 27, (1985), 113-128.
[24]
T. Clark and A. S. Evans. Foundations of the Unified Modeling Language. In D. Duke and A.
Evans editors, Proc. of the 2nd Northern Formal Methods Workshop. Springer-Verlag,1997.
[25]
Conceptual Graphs ISO Standard draft. http://users.bestweb.net/~sowa/cg/cgstand.htm
[26]
D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, and L. A.
Stein. DAML+OIL (March 2001) reference description. W3C Note, 18 December 2001.
Available at http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218.
[27]
S. CraneField, M. Purvis. UML as an ontology modeling language. In Workshop on intellingent
information integration, International Joint Conference on Artificial Intelligence, IJCAI-99,
1999.
[28]
C. De Castro, F. Grandi, and M. R. Scalas. Schema Versioning for Multitemporal Relational
Databases, Information Systems 22 (1997), no. 5: 249–290.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 74 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
[29]
M. Dean, D. Connolly, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuiness, P. F. PatelSchneider, and L. A. Stein. OWL web ontology language reference. W3C Working Draft, 31
March 2003. Available at http://www.w3.org/TR/2003/WD-owl-ref-20030331.
[30]
F. M. Donini, M. Lenzerini, D. Nardi, and A. Shaerf. A hybrid system with datalog and concept
languages. Trends in Artificial Intelligence, Volume LNAI 549, Springer Verlag, 1991.
[31]
A. Eberhart. Automatic Generation of Java/SQL based Inference Engines from RDF Schema
and RuleML. In I.Horrocks and J.Hendler eds., Proceedings of International Semantic Web
Conference 2002, Chia, Sardinia, Italy, 2002.
[32]
J. Edwards. Process Algebras for Protocol Validation and Analysis. January 2001
[33]
M. Erdmann and R. Studer. Ontologies as Conceptual Models for XML Documents. Research
report, Institute AIFB, University of Karlsruhe, 1999.
[34]
S. Evans. Reasoning with UML class diagrams. In Second IEEE Workshop on Industrial
Strength Formal Specification Techniques (WIFT’98). IEEE Computer Society Press, 1998.
[35]
A. Evans, R. France, K. Lano, and B. Rumpe. The UML as a formal modeling notation. In Proc.
of the OOPSLA’97 Workshop on Object oriented Behavioral Semantics: pages 75–81.
Technische Universitat Munchen, TUM-I9737, 1997.
[36]
D. C. Fallside. XML Schema Part 0: Primer W3C Recommendation. 2 May 2001. Available at:
http://www.w3.org/TR/xmlschema-0/
[37]
A. Farquhar, J. Fikes and J. Rice. The Ontolingua Server: A Tool for Collaborative Ontology
Construction. Knowledge Systems Laboratory Technical Report, Stanford, California, USA,
1996.
[38]
D. Fensel, F. von Harmelen, I. Horrocks, D. L. McGuinness, and P. F. Patel-Schneider. OIL: An
ontology infrastructure for the semantic web. IEEE Intelligent Systems, 16(2): 38-45, 2001.
[39]
F. Ferrandina, T. Meyer, R. Zicari, G. Ferran, and J. Madec. Schema and Database Evolution in
the O2 Object Database System. Proc. of the 21st Int’l Conf. on Very Large Databases (VLDB)
(Zurich, Switzerland), September 1995, pp. 170–181.
[40]
R. Fikes. The role of frame based representation in reasoning, Communications of the ACM,
1985.
[41]
C. Fluit, M. Sabou, F. van Harmelen. Ontology-based Information Visualization. Proceedings of
Information Visualization, 2002.
[42]
A. M. Frisch and A. G. Cohn. Thought and afterthoughts on the 1998 workshop on priciples of
hybrid reasoning. Rivista di informatica: 77-83, 1991.
[43]
E. Garcia and M. A. Sicilia. User Interface Tactics in Ontology-Based Information Seeking".
Psychology Journal, Volume 1, Number 3, 242-255, 2003.
[44]
E. García and M. A. Sicilia. Designing Ontology-Based Interactive Information Retrieval
Interfaces. Proceedings of the Workshop on Human Computer Interface for Semantic Web
and Web Applications, Springer Lecture Notes in Computer Science 2889, 152-165, 2003.
[45]
M. R. Genesereth and R.E. Fikes. Knowledge Interchange Format, Version 3.0, Reference
Manual. Technical Report, Logic-92-1, Computer Science Dept., Stanford University, 1992.
Available at http://www.cs.umbc.edu/kse/.
[46]
A. Gomez-Perez, et al. Ontological Engineering, Springer-Verlag, 2004.
[47]
S. Greenspan. Requirements Modeling. A Knowledge Representation Approach to
Requirements Definition. Ph.D. thesis, Department of Computer Science, University of
Toronto, 1984.
[48]
H. Gregersen and J. S. Jensen. Temporal Entity-Relationship models - a survey. IEEE
Transactions on Knowledge and Data Engineering 11 (1999), no. 3, 464–497.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 75 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
[49]
H. Gregersen and J.S. Jensen. Conceptual modeling of time-varying information. Tech. Report
TimeCenter TR-35, Aalborg University, Denmark, 1998.
[50]
T. R. Gruber. A Translation Approach to Portable Ontology Specification. Knowledge
Acquisition, 5(2), 199-220.
[51]
T. R. Gruber. Ontolingua: A Mechanism to Support Portable Ontologies. Knowledge Systems
Laboratory Technical Report, Stanford, California, USA, 1992
[52]
M. Gruninger. Guide to the Ontology of the Process Specification Language. In S. Staab and R.
Studer (eds.), Handbook of Ontologies, pages 575–592. Springer-Verlag, 2003.
[53]
M. Gruninger and C. Menzel. Process Specification Language: Theory and Applications. AI
Magazine, 24:63–74, 2003.
[54]
G. Guizzardi, G. Wagner, N. Guarino, P. McBrien, N. Rizopoulos. An Ontologically WellFounded Profile for UML Conceptual Models. CAiSE 2004.
[55]
R. Gupta and G. Hall, An abstraction mechanism for modeling generation. Proc. of ICDE’92,
1992, pp. 650–658.
[56]
R. Gupta and G. Hall. Modeling transition. Proc. of ICDE’91, 1991, pp. 540–549.
[57]
V. Haarslev and R. Möller. RACER system description. In Proc. Of the Int. Joint Conf. on
Automated Reasoning (IJCAR 2001), volume 2083 of Lecture Notes in Artificial Intelligence:
701-705. Springer-Verlag, 2001.
[58]
P. Hayes. RDF Semantics. Available at http://www.w3.org/TR/rdf-mt/
[59]
J. Heflin, J. Hendler and S. Luke. SHOE: A Knowledge Representation Language for Internet
Applications. Technical Report, CS-TR-4078 (UMIACS TR-99-71), Dept. of Computer Science,
University of Maryland.
[60]
J. Hendler and D. L. McGuinness. The DARPA Agent Markup Language. IEEE Intelligent
Systems, 15(6): 67-73, 2000.
[61]
I. Horrocks. Using an expressive description logic: FaCT or fiction? In Proc. Of the 6th Int.
Conf. on Principles of Knowledge Representation and Reasoning (KR ’98): pages 636-647,
1998.
[62]
I. Horrocks. P. F. Patel-Schneider, and F. von Harmelen. From SHIQ and RDF to OWL: The
Making of a Web Ontology Language. J. of Web Semantics, 1(1):pages 7-26, 2003.
[63]
I. Horrocks. U. Sattler, and S. Tobies: Practical reasoning for very expressive description
logics. Journal of the Interest Group in Pure and Applied Logic, 8(3): pages 239-264, 2000.
[64]
R. Hull and R.King. Semantic Database Modeling: Survey, Applications and Research Issues.
ACM Computing Surveys, vol. 19 n.3, 1987.
[65]
IEEE Standard Upper Ontology Working Group home page. http://suo.ieee.org/
[66]
www.interop-noe.org
[67]
P. Janecek and P. Pu. Searching with Semantics: An Interactive Visualization Technique for
Exploring an Annotated Image Collection. Proceedings of the Workshop on Human Computer
Interface for Semantic Web and Web Applications, Springer Lecture Notes in Computer
Science 2889, 187-196, 2003.
[68]
M. Jarrar, J.Demey, R. Meersman. On using Conceptual data Modeling for Ontology
Engineering. In S. Spaccapietra, S. March, K. Aberer (eds.), Journal on Data Semantics. LCNS,
vol. 2800, Springer, October 2003.
[69]
S. Jensen, J. Clifford, S. K. Gadia, P. Hayes, S. Jajodia et al. The Consensus Glossary of
Temporal Database Concepts.In O. Etzion, S. Jajodia, and S. Sripada (eds.), Temporal
Databases - Research and Practice, Springer-Verlag, 1998, pp. 367–405.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 76 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
[70]
A. Kalyanpur, D. Pastor, S. Battle, J. Padget. Automatic Mapping of OWL Ontologies into Java.
Proceedings of Sixteenth International Conference on Software Engineering and Knowledge
Engineering (SEKE), June 20-24, 2004, Banff, Canada.
[71]
P. D. Karp, K. Myers, and T. Gruber. The Generic Frame Protocol. in Proceedings of the 1995
International Joint Conference on Artificial Intelligence, pp. 768--774, 1995.
[72]
P. D. Karp. The Design Space of Frame Knowledge Representation Systems. Technical Note
520, Artificial Intelligence Center, SRI International,1993.
[73]
P.D. Karp, V.K. Chaudhri and J. Thomere. XOL: An XML-Based Ontology Exchange Language.
Version 0.4, 1999, available on line at http://www.ai.sri.com/pkarp/xol/ xol.html.
[74]
R.E. Kent. Conceptual Knowledge Markup Language: An Introduction. In Netnomics: Economic
research and electronic networking. Special Issue on Information and Communication
Middleware, vol.2, 2000.
[75]
R.E. Kent. Conceptual Knowledge Markup Language: The Central Core. In the Electronic Proc.
of the Twelfth Workshop on Knowledge Acquisition, Modeling and Management (KAW'99),
Banff, Alberta, Canada, 16–21 October 1999.
[76]
R.E. Kent. The Information Flow Foundation for Conceptual Knowledge Organization. In Proc.
of the Sixth International ISKO Conference. Advances in Knowledge Organization 7: 111–117,
Ergon Verlag, 2000.
[77]
M. Kifer, G. Lausen and J.Wu, Logical Foundations of Object-Oriented and Frame-Based
Languages.
[78]
M. Klein, D. Broekstra, F. Fensel, F. van Harmelen, and I. Horrocks. Ontologies and Schema
Languages on the Web. In D. Fensel, J. Hendler, H. Lieberman (eds.), Spinning the Semantic
Web, MIT Press, Cambridge, MA, 2003.
[79]
M. Klein, D. Fensel, F. van Harmelen, and I. Horrocks. The relation between ontologies and
schema-languages: Translating OIL-specifications in xml-schema. In Proceedings of the
ECAI'00 workshop on applications of ontologies and problem-solving methods, Berlin, August
2000.
[80]
G. Klyne and J. J. Carroll. Resource Description Framework (RDF): Concepts and abstract
syntax. W3C Working Draft, 2003. Available at http://www.w3.org/TR/2003/WD-rdf-concepts20030123.
[81]
C. Kunz and V. Botsch. Visual Representation and Contextualization of Search Results. List and
Matrix Browser, 2003.
[82]
D. B. Lenat. CYC: A Large-Scale Investment in Knowledge Infrastructure. Communications of
the ACM, 38 (11): 32-38, 1995.
[83]
H. Levesque, R. Reiter, Y. Lesperance, F. Lin and R. Scherl. Golog: A logic programming
language for dynamic domains. Journal of Logic Programming, 31:59—84, 1997.
[84]
A. Y. Levy and M. C. Rousset. CARIN: A Representation Language Combining Horn Rules and
Description Logics. In Proc. Of the 12th European Conference on Artificial Intelligence, 1996.
[85]
F. Manola and E. Miller. RDF Primer, W3C Recommendation 10 February 2004, 2004. Available
at http://www.w3.org/TR/rdf-primer/
[86]
M. Marchiori and J. Saarela. Query + Metadata + Logic = Metalog. Available at
http://www.w3.org/TandS/QL/QL98/pp/metalog.html.
[87]
J. McCarthy and P. C. Hayes. Some Philosophical Problems from the Standpoint of Artificial
Intelligence. Machine Intelligence n.4, 1969.
[88]
D. L. McGuinness, R. Fikes, J. Hendler and L. A. Stein. DAML+OIL: An Ontology Language for
the Semantic Web. IEEE Intelligent Systems, Vol. 17, No. 5, September/October 2002.
[89]
Meta-Object Facility (MOF) specification, version 1.4, available at http://www.omg.org.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 77 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
[90]
R. Milner. Communication and Concurrency. Prentice Hall International Series in Computer
Science, 1989.
[91]
M. Minsky. A Framework for Representing Knowledge. The Psychology of Computer Vision, P.
Winston (Ed.), McGraw-Hill, 1975.
[92]
G. Moore and L.M. Garshol (eds). Topic map foundational model requirements. Available at:
http://www.y12.doe.gov/sgml/sc34/document/0266.htm , 2001.
[93]
E. Motta. An Overview of the OCML Modelling Language. 8th Workshop on Knowledge
Engineering Methods and Languages (KEML '98), 1998.
[94]
P. Mutton and J. Golbeck. Visualization of Semantic Metadata and Ontologies. 2004.
[95]
J. Mylopoulos, A. Borgida, M. Jarke and M. Koubarakis. Telos: Representing Knowledge About
Information Systems. ACM Transactions on Information Systems, October 1990.
[96]
J. D. Novak. Learning, creating, and using knowledge: Concept Maps(R) as facilitative tools in
schools and corporations. Mahweh, NJ, Lawrence Erlbaum Associates, 1998.
[97]
J. D. Novak, D. B. Gowin. Learning how to learn. New York, Cambridge University Press, 1984.
[98]
OML/CKML/IFF website. http://www.ontologos.org
[99]
Ontorama. Available at http://www.ontorama.org/
[100]
OntoEdit. http://www.ontoprise.de/co_produ_tool3.htm
[101]
The Ontoviz Tab: Visualizing Protégé Ontologies. Available at
http://protege.stanford.edu/plugins/ontoviz/ontoviz.html - 2004.
[102]
OntoWeb browser. Available at http://134.184.65.65:8180/OntoWeb/Browse/index.html.
[103]
R. J. Peters and M. T. Ozsu. An Axiomatic Model of Dynamic Schema Evolution in Objectbase
Systems. ACM Transactions On Database Systems 22 (1997), no. 1, 75–114.
[104]
E. Pietriga. IsaViz, a Visual Environment for Browsing and Authoring RDF Models. Eleventh
International World Wide Web Conference Developers Day, 2002.
[105]
M. R. Quillian. Semantic memory. In M. Minsky (ed.), Semantic Information Processing. MIT
Press, 1968.
[106]
A. Rabarijoana, R. Dieng, and O. Corby. Exploitation of XML for Corporative Knowledge
Management. In D. Fensel and R. Studer (eds.), Knowledge Acquisition, Modeling, and
Management, Proceedings of the European Knowledge Acquisition Workshop (EKAW-99),
volume 1621 of Lecture Notes in Artificial Intelligence. Springer-Verlag, 1999.
[107]
R. Ramanathan, V. Guha, Douglas B. Lenat. Enabling Agents to Work Together.
Communications of the ACM, 37 (7): 126-142, 1994.
[108]
J. F. Roddick and R. T. Snodgrass, Schema Versioning, The TSQL2 Temporal Query Language,
Kluwer, 1995, pp. 427–449.
[109]
J. F. Roddick. A Survey of Schema Versioning Issues for Database Systems. Information and
Software Technology 37 (1996), no. 7, 383–393.
[110]
F. Safayeni, N. Derbentseva, A. Cañas. Concepts Maps: A Theoretical Note on Concepts and
the Need for Cyclic Concept Maps
[111]
M. Schmidt-Schauβ and G. Smolka. Attributive concept descriptions with complements.
Artificial Intelligence, 48(1): 1-26, 1991.
[112]
Semantic Web & Ontology Related Initiatives. http://ontobroker.semanticweb.org/
[113]
J. Siméon and P. Wadler. The essence of XML. In Conference Record of POPL 2003: The 30th
SIGPLAN-SIGACT Symposium on Principles of Programming Languages, New Orleans,
Louisisana: pages 1-13, January 15-17, 2003.
[114]
S. W. Smoliar. Sowa's book review. Artificial Intelligence, 33, (1987), 259-266.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 78 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
[115]
J. Sowa. Conceptual Structures, Addison-Wesley Reading, 1984.
[116]
S. Spaccapietra, C. Parent, and E. Zimanyi. Modeling time from a conceptual perspective. Int.
Conf. on Information and Knowledge Management (CIKM98), 1998.
[117]
M. Stanley. CML: A Knowledge Representation Language with Applications to Requirements
Modeling. M.Sc. thesis, Department of Computer Science, University of Toronto, 1986.
[118]
R. T. Snodgrass. The temporal query language tquel. ACM Transaction on Database Systems
12 (1987), no. 2, 247–298.
[119]
B. Tauzovich. Towards temporal extensions to the entity-relationship model. Proc. of the 10th
International Conference on the Entity-Relationship Approach (ER’91), 1991, pp. 163–79.
[120]
C. Theodoulidis, P. Loucopoulos, and B. Wangler. A conceptual modeling formalism for
temporal database applications. Information Systems 16 (1991), no. 3, 401–416.
[121]
TopicMaps.org website. http://www.topicmaps.org
[122]
Unified Modeling Language (UML) specification, version 1.5, Available at http://www.omg.org.
[123]
www.w3.org
[124]
WeKB. Available at http://meganesia.int.gu.edu.au/~phmartin/WebKB/
[125]
M. Wermelinger. Conceptual Graphs and First Order Logic. LNCS 954. 1995.
[126]
W. A. Woods. What's in a link: foundations for semantic networks. In D.G. Bobrow and A.M.
Collins, editors, Representation and Understanding: Studies in Cognitive Science, pages 35-82.
New York: Academic Press, 1975.
[127]
W. A. Woods and J. G. Schmolze. The KL-ONE family. In F. W. Lehmann, editor, Semantic
Networks in Artificial Intelligence: 133–178, 1992. Pergamon Press. Published as a special
issue of Computers & Mathematics with Applications, Volume 23, Number 2–9.
[128]
ISO/IEC 13250, Topic Maps, Second Edition, 19 May 2002, available at
http://www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd-ed-v2.pdf
[129]
XML Metadata Interchange (XMI) specification, version 1.2. Available at: http://www.omg.org
[130]
XML-Schema (W3C web site). Available at: http://www.w3.org/XML/Schema .
[131]
S.Pepper and G. Moore (eds), XML Topic Maps (XTM) 1.0. Available at
http://www.topicmaps.org/xtm, 2001.
[132]
XSB inc. website. http://www.xsb.com/
[133]
V. Haarslev, R. Möller. Description of the RACER System and its Applications. In Proc. of the
International Workshop on Description Logics (DL-2001), Stanford, USA, 1.-3. August 2001.
[134]
http://www.commonkads.uva.nl/
[135]
http://www.jfsowa.com/peirce/ms514.htm
[136]
http://www.ruleml.org/
[137]
J.W. Lloyd, Foundations of logic programming (second, extended edition), Springer series in
symbolic computation. Springer-Verlag, New York, 1987.
[138]
M. Schmidt-Schauß, Subsumption in KL-ONE is Undecidable.. Proc. of KR'89, pages 421-431,
Morgan Kaufmann.
[139]
L. Sterling, E. Shapiro, The Art of Prolog, MIT Press, Cambridge, Massachusetts 1986.
[140]
http://www.hpl.hp.com/semweb/jena.htm
[141]
Business Process Trends Whitepapers. http://www.bptrends.com/ “An Introduction to the
Supply Chain Council’s SCOR Methodology”, January 2003 “Second Generation Business
Process Methodologies”, May 2003
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 79 / 244
IP- Project
ATHENA -Project
Document
[142]
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Semagix. Official web site. http://www.semagix.com
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 80 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Section II
Ontology management tools comparison
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 81 / 244
IP- Project
ATHENA -Project
Document
3
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Ontology management system comparison
The task of building ontologies is in general not linear at all, since it is typically approached from
several perspectives at once, both top-down and bottom-up. It is also a substantially iterative process
where skeleton structures of core concepts are gradually extended with more refined and more
peripheral concepts, and these are more tightly interwoven with additional relations, spanning. So the
building of an adequate ontology spans problem specification, domain knowledge acquisition and
analysis, conceptual design and commitment to community ontologies, iterative construction and
testing, publishing the ontology as a terminology, and possibly populating a conforming knowledge
base with ontology individuals. While the process may be strictly a manual exercise, there are tools
available that can automate portions of it. For example, linguistic tools can analyze the content of
domain documents in order to synthesize ontology terms themselves, or to extract content
corresponding to a domain ontology as individuals forming a knowledge base. Building complex
ontologies today usually relies on the manual composition of the ontology using an ontology editor for
the chosen ontology languages(s).
This survey covers software tools that have mainly manual ontology editing and management
capabilities and therefore that may be useful for building ontology schemas alone or together with
instance data.
Despite the immaturity of the field, or perhaps because of it, it is possible to identify a surprising
number of ontology editors. In this section we focus solely on the more interesting and extensive
ontology tools that
1) have not only ontology editing but also instantiating capabilities
2) are known to be in use today
3) are the most targeted at achieving effective semantic interoperability9
Such editing tools are not necessarily production level development tools, and some may offer
only limited functionality, usability and user support.
3.1
Ontology interoperability and standards
Ontology building might result in a fragmented practice. The situation, in part, is a result of the
proliferation of logic languages and information models that have combined to yield even more
ontology forms and editing environments. These tools and methodologies, along with the ontologies
built with them, generally exist without proven interoperability.
As a matter of facts, ontologies are for sharing: they are intended to serve as consensual joint
points to exchange and interpret information. Clearly, the wider the range of applications and other
ontologies that can use an ontology, the greater its utility and the mutual utility of the interrelating
ontologies. This requires formal compatibility on syntactic levels as well as semantic levels. One
consideration in the enterprise realm, for example, is the ability of a domain ontology to accommodate
specialized XML languages and controlled vocabularies being adopted as standards in various
industries, in order to describe and harmonize the meta-content being interchanged. None of the
current ontology editors address this capability fully, however most providers of tools are moving in this
direction.
Interoperability, instead, is being addressed simply through an editor's ability to import and export
ontologies in different language serializations. Some tools like Stanford Knowledge Systems Lab's
Ontolingua offer a wide range of translations, while most are limited. Importing or exporting ontologies
in languages like DAML+OIL and OWL usually means that the translation is only partial and
expressiveness is lost.
The W3C recently recommended the OWL language and RDF for building web ontologies. These
language specifications were developed over several years both within and outside of the organization,
and OWL is rapidly replacing its predecessor DAML+OIL with the blessing of the DAML Office in the
Department of Defense, which funded much of its early development. Commensurate W3C
standardization activities are now underway to expand the development framework for building and
using web ontologies with web services, deductive rules, and optimized query languages.
9
The goal of semantic interoperability is to allow the (seamless) cooperation of two software
applications that were not initially developed for this purpose.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 82 / 244
IP- Project
ATHENA -Project
Document
3.2
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Survey criteria
In order to give a clear and simple comparison, we use an evaluation table to explain differences
between tools referring to some significant criteria. These criteria are:
Meta model features
•
•
•
•
•
•
Base Language: The native or primary language used to encode the ontology.
Compatibility to Standards (OWL10 compatibility): Ability to handle OWL ontologies; Web
Ontology Language the ontology representation language recommended by W3C consortium,
thus both fitting Web standards and defined my mean of industry consensus.
Application Domain adequacy and modelling templates: Existence of predefined categories for
concepts, and of predefined domain-dependent templates.
Constraints: The ability to model constraints on concepts and relations.
Advanced Queries: The model enables advanced queries, including similarity. For instance the
OMS might handle similarity relationships between entities, or it might include some kind of
taxonomic or intelligent reasoning feature for matching criteria with a certain degree of
confidence.
Instance handling: The ability to instantiate models.
Technical and functional features
•
•
•
•
•
•
•
•
•
•
•
•
•
Web Orientation: The OMS is a web application and is accessible via the web.
Multi User Support: The OMS allows and facilitate concurrent development of the built ontology.
Web Services enabled: Functionalities are published as web service, plus the OMS is able to
invoke outer web services.
Consistency Checks: The degree to which the syntactic, referential and/or logical correctness of
the ontology can be verified automatically.
Merging: Support for easily comparing and merging independent built ontologies.
Ontology Extraction: Ability to use text documents as the initial source for creating an ontology.
Lexical Support: Capabilities for lexical referencing, possibly multi-lingual, of ontology elements
(e.g., synonyms) and processing lexical content (e.g., searching/filtering ontology terms).
Query Tool: Ability to query the ontology through more or less sophisticated reasoning
mechanisms.
Graphical View(s): The extent to which the built ontology can be view and/or compared directly in
graphic form.
Graphical Editing: The extent to which the built ontology can be created, debugged, edited
directly in graphic form.
Import/Export formats: Other languages the built ontology can be serialized in.
Log Facilities: Real time recording of users activities for later access or analysis.
Versioning system: CVS control.
In the forthcoming table, we assign for each survey criterion a value from 0 to 3 which indicates
the fulfilling degree:
•
0 – not supported
•
1 – low
•
2 – medium
•
3 – high
10
The Web semantic OWL language extends earlier W3C standards, such as RDF, with richer
modelling primitives, to provide a set of constructs to define web ontologies. It sets the basic
infrastructure to build some simple inferences between web resources and enabling knowledge
management architecture. The current OWL language definition has a clean and well defined
semantic, it’s a W3C recommendation and it’s based on the DAML+OIL language which was built on
top of the original DAML ontology project, called DAML-ONT, with many of the components of the OIL
language.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 83 / 244
IP- Project
ATHENA -Project
Document
3.3
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Surveyed tools
3.3.1
KAON
KAON [9] is an open-source ontology management infrastructure targeted for business
applications. It includes a comprehensive tool suite allowing easy ontology creation and management
and provides a framework for building ontology-based applications. An important focus of KAON is
scalable and efficient reasoning with ontologies.
•
•
KAON provides two user-level applications and also modules for software development:
OiModeler: It is an ontology editor and provides support for ontology creation and maintenance.
The distinguishing features of OILmodeler are its support for manipulation of large ontologies and
support for user-directed evolution of ontologies. OILmodeler also provides an open and
extensible platform to embed other ontology-aware software modules
KAON PORTAL: It provides a simple framework for navigating and searching ontologies through
Web browsers.
Figure 4.
3.3.2
KAON Workbench
Ontolingua (with Chimaera)
Ontolingua [10] provides a distributed web-based collaborative environment to browse, create,
edit, modify, and use ontologies. You can use Ontolingua only with your browser, using the service
offered by the Stanford University.
Chimaera is a software system that supports users in creating and maintaining distributed
ontologies on the web. Two major functions it supports are merging multiple ontologies together and
diagnosing individual or multiple ontologies. It supports users in such tasks as loading knowledge
bases in differing formats, reorganizing taxonomies, resolving name conflicts, browsing ontologies,
editing terms, etc.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 84 / 244
IP- Project
ATHENA -Project
Document
Figure 5.
3.3.3
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Ontolingua web page
OilEd
OilEd [12] is an open source ontology editor allowing the user to build ontologies using DAML+OIL
semantic language. The current versions of OilEd does not provide a full ontology development
environment, it will not actively support the development of large-scale ontologies, the migration and
integration of ontologies, versioning, argumentation and many other activities that are involved in
ontology construction.
Figure 6.
OilED
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 85 / 244
IP- Project
ATHENA -Project
Document
3.3.4
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Protégé 2000
Protégé [11] is an extensible, platform-independent environment for creating and editing
ontologies and knowledge bases that allows the construction of a domain ontology, the customization
of data entry forms and the following data entry. It is also a platform which can be extended (via plugins) with graphical widgets for tables, diagrams, components to access other knowledge-based
systems embedded applications and a library which other applications can use to access and display
knowledge bases.
Protégé is an open source project written in JAVA and it ca be used also as Eclipse plug-in. It is
the most used ontology tool and in the newer versions is included the OWL plug-in to manage
ontologies based on this semantic language.
Figure 7.
Protégé 2000
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 86 / 244
IP- Project
ATHENA -Project
Document
3.3.5
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
pOWL
pOWL [21][22][23] is an open-source framework for parsing, storing, querying, manipulating,
serving and serializing OWL knowledge bases in a collaborative web enabled environment for open
web application platforms based on PHP. It is based on a four tiers architecture:
•
pOWL stores: An SQL compatible relational database backend.
•
RDFAPI, RDFSAPI, OWLAPI: APIs for handling RDF, RDF-Schema (RDFS) and OWL languages
•
pOWL API: Containing classes and functions to build web applications using the main APIs
•
User interface: A set of PHP pages combining widgets provided by pOWL API for accessing
(browsing, viewing, editing) model data in a pOWL store.
Figure 8.
pOWL
pOWL enables the creation of a peer-to-peer network of knowledge bases supporting the
conjunction of distributed pOWL registries.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 87 / 244
IP- Project
ATHENA -Project
Document
3.4
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Survey results
Meta model features
KAON
Base
Language
Standards
compatibility
Application
Domain
adequacy and
supporting
Constraints
Advanced
Queries
Instance
handling
RDF(S).
Protégé 2000
OilEd
pOWL
OKBC + CLOS
based metamodels.
3 – OWL
plugin.
DAML+OIL.
0 – DAML+OIL 3 – OWL and
is not fully OWL RDF API.
compliant even
though it
originated OWL.
They say
DAML+OIL
support is under
development.
2 - OWL, DAML
and DAML-S are
axiomatized as
ontologies.
Chimaera
accepts OWL
and DAML.
1 – Only
classes and
properties. No
supporting.
1 – Highly
expressive
potential, but
only general
purpose
templates.
1 – No
supporting.
1 – No
supporting.
1 – No
supporting.
1 – Simple
constraints
(e.g.: domain
and relation
range).
2 – OWL model 2 – FaCT
constraints (e.g.: model
cardinality and
constraints.
relation
attributes
constraints such
as: transitivity,
symmetry...
2 – OWL
model
constraints.
2 – OWL
model
constraints.
1 – Taxonomic
reasoning
(including
specialization
hierarchies).
2 - Taxonomic
reasoning and
equivalence
relations.
3 – RDQL
query
builder and
Fulltext
search.
0 – No
Taxonomic
reasoner
included.
3
3
3
3
1 – Only
RDF(S) W3C
recommended
format is
natively
supported, not
OWL.
050404_ATHENA_DA31_PartA_V10.doc
1 - Taxonomic
reasoning
based on the
CORBA-FaCT
reasoner or
subsumptions
only.
0
CONFIDENTIAL
RDF(S)
OWL.
Ontolingua
Ontolingua.
Page 88 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Technical and functional features
KAON
Protégé 2000
2 - Browsing
ontologies via
KAON Portal.
Web
Orientation
Multi User
Support
1 - standalone
(local
database) or
client-server
architecture
(remote
database)
Web access
(via applets) for
browsing only.
1 - Concurrent 2 - Only when
Web access
client is
for browsing
accessing a
only. Remote
server DB: no
connection to
check-in,
shared
check-out.
database. No
“Metaproject”
check-in,
feature still
check-out.
under
development.
2 - It is possible 2 - It is
to create WSs possible to
via API.
create WSs via
API.
OilEd
3 - PHP
based.
3 - Web based.
0 - It is
intended for a
single-user
ontology
editing.
3 - It is for
collaborative
work.
1 - Write/Only
access locks
Ontology.
0
3 - It is
0
possible to
access via
WSs.
Different pOW
installations
may share
models by
using Web
Services.
2 - Elaborate
with Chimaera;
Theorem
proving (via
JTP).
2
2 - Plug-ins for
adding &
checking
constraint
axioms: PAL.
FaCT.
1 - Only
FaCT
oriented
checks such
as
subsumption.
0
2 - Semi
automatic
merging.
2 - Semiautomatic via
Chimaera.
2 - Easy to
use Text-toOnto wizard.
2 - Explicit
lexical
representation
in model.
Multilingual.
0
1 - Including
Ontologies
leads to
heavy
manual work.
0
2 - Wordnet
plugin enables
API calls also
with wildcards.
1 - Limited
synonyms.
1 - Only Search
of Terms in all
loaded
ontologies.
2 - Average
complexity
queries.
0
Consistency
Checks
Merging
Lexical
Support
Query Tool
Ontolingua
0
Web Services
enabled
Ontology
Extraction
pOWL
1 - Simple
queries.
050404_ATHENA_DA31_PartA_V10.doc
0
3 - RDQL
query builder.
CONFIDENTIAL
1 - Simple
queries.
Page 89 / 244
IP- Project
ATHENA -Project
Document
Graphical
View(s)
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
KAON
Protégé 2000
OilEd
2 - Built-in
graphic
viewer.
2 - Separate
plugins for
viewing nested
graphic views.
1 - Browsing
Graphviz files
of class
subsumption
only.
2 - Web
based
graphic
interface.
0
0
2 - Separate
plugins for
editing nested
graphic views.
3 - Plugins
available for
import/export
from/to OWL,
RDF(S), XML
Schema,
DAML+OIL.
In the future it
is possible to
create new
plug-ins to
support new
semantic
languages.
0
2 - Web
based
graphic
interface.
3Syntactically
pOWL may
import and
export model
data in
different
serialization
formats
(RDF/XML,
N3, N-Triple).
Structurally it
allows
viewing and
editing model
data from
different
points of view
(DL axioms,
database like
or RDF
statements).
Semantically
it supports
integrating
models of
different
semantic
domains.
0
0
Graphical
Editing
1 - Limited
number of
supported
formats.
Import/Export
formats
2 - Limited
number of
supported
formats
(RDFS;
SHIQ).
0
0
1 - Only
exceptions.
0
0
0
pOWL
507849
04.04.05
Ontolingua
3 - Import &
Export:
DAML+OIL;
KIF; OKBC;
Loom; Prolog;
Ontolingua;
CLIPS. Import
only: Classic;
Ocelot;
Protégé.
0
Log Facilities
3Versioning
system
enables
rollback of
every editing
action.
Versioning
System
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
0
Page 90 / 244
IP- Project
ATHENA -Project
Document
3.5
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Conclusion
An even too complete comparison (not evaluation though) of Ontology systems was published on
O’Reilly’s XML.com reputable web-zine by Michael Denny [3][4]. The revised version of his Ontology
Editor Survey includes summary information on nearly 90 different semantic-oriented tools, some of
them even questionably included in the commentary, since they are better classified as editors of
some language or formalism (like UML) on top of which it is theoretically possible, but practically
unhandy, to build ontologies.
With respect to the ATHENA business and technological objectives, we can conclude regarding
usefulness and usability of the evaluated tools, that, frankly speaking, ontology editors vary
considerably in their overall look and feel to the user. As a matter of facts, we did not attempt to
compare editors under use in real test beds, but a few general observations can be put forward: in
terms of breadth and variety of features, especially as they relate to interfacing with other information
system components, Protégé 2000 from Stanford Medical Informatics offers an editing environment
with several third party plug-ins. This powerful plug-ins system allows the creation of new specific
components for the tool, increasing the life of this tool and allowing the support of new languages. The
main problem of this tool is that it is not web-based but there is only a stand-alone version.
pOWL is the most powerful web-based semantic tool and it is written in PHP in a four tiers
architecture that allows the use of different sets of PHP library which can be used to build add-on and
new products. It supports also the RDQL language to build semantic queries and the multi-user work.
From a strict ontology language point of view, Ontolingua and OpenCyc offer, or will offer,
development environments affording highly expressive and complete ontology specifications. OilEd
appears to offer strong support for composing description logic expressions, but it lacks, even more
than the above mentioned solutions, effective productivity tools for real world environments.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 91 / 244
IP- Project
ATHENA -Project
Document
4
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Inference engines comparison
The inference engine is the component in a semantic-aware application that takes semantics and
ontology definitions and goes on to deduce relationships and handle queries. Creating an inference
engine that is fast, expressive and able to handle complexities like inconsistencies is a complex
undertaking. As inference engines improve and become more powerful, applications of the Semantic
Web will provide increased benefit to the users.
The primary use of inference is to support the use of languages such as RDFS and OWL which
allow additional facts to be inferred from instance data and class descriptions.
We will try to use the term inference to refer to the abstract process of deriving additional
information and the term inference engine (a.k.a reasoner) to refer to a specific software component
that performs this task.
Some of the hereafter surveyed tools are natively integrated with some of the above mentioned
Ontology Management Systems.
4.1
Survey criteria
Also for the inference engines we create an evaluation table to explain differences between tools
using significant criteria. These criteria are:
•
Rule Base Language: Which primary language is used to express the rules.
•
OWL compatibility: Ability to handle OWL ontologies; Web Ontology Language the ontology
representation language recommended by W3C consortium, thus both fitting Web standards and
defined my mean of industry consensus.
•
Supported reasoning services:
o Taxonomy reasoning: The engine is able to infer facts based upon a taxonomy of concepts.
o Forward and Backward or Hybrid Chaining: The ability to process forward or backward chaining
of inference rules, or to process hybrid forward/backward chaining.
o Consistency checking: Respect to the constraints defined in the ontology.
o Instance checking: Given a concept instance, is the reasoning able to tell of which concept it is
instance?
•
API enabled: The reasoner is accessible via one or more APIs.
•
Web Services enabled: Functionalities are published as web service, plus the OMS is able to
invoke outer web services.
•
Rule Tracing: The log of the applied rules for a given query.
In the forthcoming tables, we assign for each survey criterion a value from 0 to 3 which indicates
the fulfilling degree:
•
0 – not supported
•
1 – low
•
2 – medium
•
3 – high
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 92 / 244
IP- Project
ATHENA -Project
Document
4.2
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Survey results
JENA [14]
Jena 2 is an
environment for
reasoner plug-ins.
Available
reasoners:
RDF(S) reasoner:
it supports almost
all of the RDFS
entailments
described by the
RDF Core working
group.
Rule Base
Language
MetaLog [13]
JESS [15]
RDF(S)
MetaLog is not
for the industry,
but for
showcase of
Semantic Web.
It is built on top
of SWI-Prolog
and includes
also a friendly
PseudoNaturalLanguage user
interface.
CLIPS
The core
Jess
language is
still
compatible
with CLIPS,
an expert
system shell
that inspired
the JESS
Java
implementati
on.
SWAP
CWM [16]
RDF/N3
The
Semantic
Web
Application
Platform
includes a
Pytonbased rule
processor
called
CWM.
OWL/FB reasoner:
useful but
incomplete
implementation of
the OWL/Lite
subset of the
OWL/Full language.
RACER [36]
DAML+OIL
"Renamed
ABox and
Concept
Expression
Reasoner
(RACER)" is
a description
logic
reasoner that
works as a
server and
accepts
connections
via HTTP and
TCP/IP.
RDF/RDFS/D
AML/OWL
Generic rule
reasoner: it
supports user
defined rules,
forward chaining,
tabled backward
chaining and hybrid
execution
strategies.
OWL
compatib.
Taxonomic
Reasoning
Forward and
Backward
Chaining
0 - Planned in
the future.
0 - Only
RDF.
1 - Not all OWL/Lite
is supported, let
alone full OWL.
Works in progress
focus more on
stability and
scalability than
completeness.
0
0 - A distinct
taxonomy
construction phase
is being planned.
0
0
0
3 - Forward
chaining, tabled
backward chaining
and hybrid
execution
strategies.
1 - Forward
only, like
Prolog, so far.
2 - Jess's
backward
chaining is a
bit
unorthodox.
1Forward
only.
0
0
0
Consistency 3 - Rules Validation
can be designed to
Checking
050404_ATHENA_DA31_PartA_V10.doc
2 - OWL
enabled.
Includes
OWL
vocabulary.
CONFIDENTIAL
0
2
Page 93 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
JENA [14]
MetaLog [13]
JESS [15]
507849
04.04.05
SWAP
CWM [16]
RACER [36]
0
0
run on demand.
Instance
Checking
API Enabled
Web Service
Enabled
2 - Syntax
Checking via beta
plugin.
0
0
3 - For each
reasoner there is a
Java factory class,
an instance of
which can create
instances of the
reasoner.
0
1 - Only
3 - Jess is a
command
Java
line.
scripting
environment,
from which
you can create
Java objects
and call Java
methods of the
Jess object
model.
2 - APIs are
available for
Java, C++,
and Common
Lisp
2 - It is possible to
create WSs via
APIs.
0 - No way.
2 - It is
possible to
create WSs
via APIs.
1 - It is
possible to
wrap
commandline calls
with WSs.
2 - It is
possible to
wrap HTTP
calls with
WSs.
0 - Not internally.
0
0 - Improved
error
reporting is
planned.
0
0
Rule Tracing
4.3
Conclusion
From the table above is simple to understand that JENA offers the most powerful inference
engine. JENA is not only an inference engine but it is also a complete open source (supported by HP)
framework that provides APIs for RDF and OWL, persistent storage capability (with MySQL,
PostgreSQL and Oracle databases) and a query language for RDF (RDQL).
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 94 / 244
IP- Project
ATHENA -Project
Document
5
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Other tools and methodologies not considered in the surveys
There are many other tools and methodologies about ontologies management that we have not
included in our survey because we have concentrated our work on the most popular software. In this
section we want only to write a brief description with some comments about some of them. This part is
written using also the chapter II.3.2.2 of the INTEROP state of the art on ontologies and semantic [8].
•
Apollo: It is a user-friendly knowledge modeling application. Modeling is based on the basic
primitives, such as classes, instances, functions, relationships, etc.. The internal model is build as
a frame system according to the internal model of the OKBC protocol. Apollo performs a full
consistency check while editing. The application is not bound to any representation language and
can be adapted to support different storage formats through I/O plug-in. The user interface has an
open architecture (view based) and allows for implementing additional views of the knowledge
base. The software is written in Java and is available for the download.
•
JOE (Java Ontology Editor): It is a tool for building and viewing ontologies developed in the
Centre for Information Technology, University of South Carolina (JOE 2003). The JOE basic idea
is to provide a knowledge management tool that supports multiple cooperative users and
distributed, heterogeneous operating environments. Ontologies are represented using a framebased approach and can be viewed in three different formats: as ER diagrams, as a hierarchies
akin to Microsoft Windows file manager, or as a graphical tree structures. JOE allows for writing
queries by using a visual representation of the ontology and a point-and-click approach for adding
query conditions.OntoSaurus: It is a browser for LOOM-based ontologies; LOOM is a variant of
description logics supporting concept classification and instance matching.
•
Chimaera: It is a tool mainly intended for merging knowledge base (KB) fragments, which also
supports users in creating and maintaining distributed ontologies on the Web. Its two major
functions are merging multiple ontologies and diagnosing individual or multiple ontologies. It
supports users in reorganizing taxonomies, resolving name conflicts, browsing ontologies, editing
terms, etc. The process of KB merging typically involves activities as resolving name conflicts and
aligning the taxonomy. This tool has special support for finding name conflicts and for pointing out
interesting places in the merged taxonomy.
•
ICOM: It is a tool supporting the conceptual design phase of an information system, and in
particular of an integration information system, such as a data warehouse. The tool is an
evolution of part of the conceptual modeling demonstrators suite (Jarke et al 2000) developed
within the European ESPRIT Long Term Research Data Warehouse Quality (DWQ) project
(Jarke et al 1999). ICOM adopts an extended Entity-Relationship (EER) conceptual data model,
enriched with multidimensional aggregations and interschema constraints. ICOM is fully
integrated with a very powerful description logics reasoning server which acts as a background
inference engine. The tool supports multiple schemas with interschema constraints but it turned
out to be extremely useful also in supporting the conceptual modeling of "classical'' databases
involving a single rich schema with integrity constraints, and in designing ontologies for various
purposes. ICOM reasons with (multiple) diagrams by encoding them in a single description logic
knowledge base, and shows the result of any deductions such as inferred links, new or stricter
constraints, and inconsistent entities or relationships. Theoretical results from the DWQ project
guarantee the correctness and the completeness of the reasoning process: the system uses the
SHIQ description logic, as a mean to provide the core expressivity of the DLR logic developed by
(Calvanese et al 1998). ICOM has been installed in more than 1,200 locations.
•
The MOMIS methodology and SI-Designer: It follows a semantic approach to information
integration based on the object-oriented logical schema of the information sources. In order to
create a global virtual schema of involved sources, MOMIS generates a common thesaurus of
terminological intensional and extensional relationships describing intra and inter-schema
knowledge about classes and attributes of the source schemata. On the basis of the common
thesaurus content, MOMIS evaluates affinity between intra and inter-sources classes and groups
similar classes together in clusters using hierarchical clustering techniques. A global class, that
becomes representative of all the classes belonging to the cluster, is defined for each cluster. The
global view for the involved source data consists of all the global classes. A graphical tool, the
Source Integration Designer, SI-Designer, supports the MOMIS methodology (Bergamaschi et al
1999).
•
SymOntoX: It is an ontology management system that makes use of a web-based interface and
targets specifically the management of ontologies for the eletronic business domain. SymOntoX
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 95 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
allows the management for multiple ontologies, supports access rights for different user profiles,
and supports multiple languages. It provides a set of feature types to describe concepts: similar
concepts, narrower concepts, part-of concepts, and attributes of concepts. By means of access
rights, certain roles can be defined for the creation of ontologies. For example, only a super user
can propose new terms while ordinary users are restricted to browsing.
WebOnto: It is a front-end to the OCML ontology definition language. It is largely compatible with
Ontolingua and provides a graphical user interface integrated into web browsers via Java applets.
OCML supports rules and definitions for relations and functions, it checks consistency constraints
and correct typing of attribute values.
WebOde: It is an extensible ontology engineering suite with ports to different external formals
(DAML-OIL, RDF(S), F-Logic, etc.). It includes an editor and tools for merging and integration of
ontologies and an editor for first-order axioms and querying support via its internal concept
definition format OKBC or via Prolog. Several plugins have been developed, such as ODEClean
for checking consistency of concept taxonomies.
OntoEdit: It is another ontology engineering suite that supports import and export in multiple
formats, stresses inferences, frames-based concept definitions and axioms that can be
represented in F-Logic, Prolog, Datalog. It offers a graphical visualization tool and it is provided in
a free or commercial version. It has also a merging tool called FCA-merge toolset.
PROMPT: It is a merge tool for Protégé that supports deep/shallow copying of concept definitions
from an ontology to other one, merging of classes and matching of similar concepts.
ONIONS (ONtological Integration Of Naive Sources): It is a methodology for conceptual analysis
and ontological integration. It aims to provide extensive axiomatisation, clear semantics, and
ontological domain terminologies that are to be integrated or merged. Extensive axiomatisation is
obtained through a careful conceptual analysis of the terminological sources and their
representation in a logical language with a rigorous semantics. Analysis ontological depth is
obtained by reusing a library of foundational ontologies, on which the axiomatisation depends.
•
•
•
•
•
5.1
IBM Ontology Framework
IBM has released some intelligent tools for semantic support and semantic programming. They
build a complete framework that cover three major semantic areas:
1) Ontology Specification Languages
2) Ontology Management Systems
3) Ontology Query Languages
5.1.1
IBM Integrated Ontology Development Toolkit
http://www.alphaworks.ibm.com/tech/semanticstk
Formerly named IBM Semantics Toolkit, it is designed for storage, manipulation, query, and
inference of ontologies and corresponding instances. A major purpose is to establish an end-to-end
ontology engineering environment tightly integrated with dominant Meta-Object Facility (MOF)-based
modeling and application development tools. As such, it provides a platform for managing RDF
metadata and reduces the amount of programming required for the development of metadata-intensive
applications. It contains three main components:
•
Orient: It is visual ontology management tool based on the Eclipse platform. It supports RDF(S)
and it is integrated with Eclipse Modeling Framework (EMF). Next releases will support OWL
language too.
•
EODM: It provides an high performance OO interface for managing ontologies.
•
RStar: It is an high performance metadata repository based on Resource Description Framework
(RDF). It uses an RDBMS to store data and it defines a query language called RSQL for the
information retrieval. It supplies a set of APIs to effectively load, retrieve and manage RDF data
on DB2 and CloudScape databases.
5.1.2
IBM Ontology Management System (SNOBASE)
http://www.alphaworks.ibm.com/tech/snobase
It is a is a framework for loading ontologies from files and via the Internet and for locally creating,
modifying, querying, and storing ontologies. It provides a mechanism for querying ontologies and an
easy-to-use programming interface for interacting with vocabularies of standard ontology specification
languages such as RDF, RDF Schema, DAML+OIL, and OWL.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 96 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Internally, the system uses an inference engine, an ontology persistent store, an ontology
directory and ontology source connectors. Applications can query against the created ontology models
and the inference engine deduces the answers and returns results sets similar to JDBC (Java Data
Base Connectivity) result sets.
5.1.3
IBM Ontology-based Web Services for Business Integration
http://www.alphaworks.ibm.com/tech/owsbi
Ontology-based Web Services for Business Integration is a semantic Web services proof-ofconcept demonstration for the industrial sector that shows service discovery, composition, and
business process transformation. It supports the infrastructure for next-generation, semantic Web
services middleware that enables business process integration, including business-to-business (B2B)
exchange. It is a demonstration of technology that can facilitate enhanced discovery, composition, and
transformation of business processes through semantic enablement and intelligent agents.
5.2
KPONTOLOGY
KONTOLOGY [32] is an open source library for managing ontologies that offers an abstraction
layer on top of different ontology engines, such as JENA, Sesame and WebODE. Using
KPONTOLOGY allows working with high level concepts like Class, Attribute and Instance, and not
worrying about semantic specific notions, such as triples, instances, properties, etc..
At the moment exist four implementations, for JENA 2.0, JENA 1.6, Sesame 1.0 and WebODE but
the only documentation available is the online Javadoc.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 97 / 244
IP- Project
ATHENA -Project
Document
6
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
EAI solutions (Enterprise Application Integration)
The main goal of the Athena project is to allow interoperability among enterprises. The most
important IT vendors offer products and solutions for solving interoperability problems under the name
EAI. In this context we need to understand the capabilities of these products that can be used to solve
interoperability issues and could be considered and integrated in the Athena framework.
It is not simple to find a common explanation of what EAI means and it is also difficult to specify
the real EAI market competitors because new kinds of vendors can be seen as new potential players
of this market, such as Application Server Vendors, BPM/workflow Vendors, Web services Vendors
and so on. The picture below shows the state of the market (Gartner Group).
Figure 9.
EAI market
From the picture is simple to understand that the main difference between the leaders and the rest
of the players is the ability to supply a stable and complete execution platform. From other market data
is possible to characterize the market share of the main competitors. IBM, TIBCO and webMethods
reach more than 40% of the market. Obviously in our survey we are going to consider only the
solutions of these main players.
6.1
EAI in the semantic context
Athena project needs to understand the EAI solutions because these products try to solve the
interoperability problem in an efficiency way. The original hand-coded integration needs that each
application has to be connected to each other, instead the EAI hub approach allows the creation of a
single framework that solves the connection among different software and data.
In this context is necessary also to understand if semantic and ontologies are common
components used by the today EAI solution. In the following section we describe some solutions
analysing the four basic components of every EAI product:
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 98 / 244
IP- Project
ATHENA -Project
Document
•
•
•
•
6.2
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Communication: How the EAI tools communicate with the linked application. There are two main
styles of communication, Message Queuing (asynchronous and can be optimised) and Message
Bus (more scalable but Potential for bottlenecks if not configured correctly.
Data integration: The capability to integrate and manage legacy data.
Application integration: The capability to integrate legacy application into the EAI platform.
Process integration: The capability to manage business processes and workflow.
EAI solutions
In this section we explain a brief description of the main EAI products on the market and a table
that show a join view of the different solutions
6.2.1
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
6.2.2
•
•
•
•
•
•
•
IBM - Web Sphere Business Integration [25]
Communication
J2EE 1.3 support (support for some features planned for J2EE 1.4).
Full XML support.
Full Web services support.
Support for private UDDI registries.
Web Services Gateway.
Embedded HTTP server.
Java Message Service (JMS) support.
Data Integration
Supports optimized "any-to-any" transformation of EDI, XML, and record-oriented application data
formats.
Data validation and standards compliance function to provide industry-leading support for HIPAA,
ANSI X12 embedded HL7, and other industry formats.
Allows direct import of industry-standard or user-defined XML DTDs for mapping and translation.
Provides a mapping tool to build EDI, XML, and application data format transformations.
Application Integration
Integrated tool support for using J2EE Connector Architecture (JCA) 1.0 resource adapters to
access back-end systems.
Enhanced tool integration for JCA adapters with tool plug-in extensions.
Tools for creating services out of JCA resource adapters.
Wizards to manage the low-level data handling requirements for JCA resource adapters.
Mapping/transformation facilities are well defined and providing with for the entire suite of
WebSphere Business Integration Adapters Support to many Environments.
Transaction information from cross-industry and industry-specific packaged applications and
connect them to a central hub.
Process Integration
Provides pre-built solutions for business process automation. Application-independent
Collaborations graphically define end-to-end processes and encapsulate basic integration and
business rules for business processes.
WebSphere Business Integration Collaborations are customizable business process templates
that deliver most of the necessary code for a wide variety of business processes running on the
WebSphere Business Integration Server.
Microsoft – BizTalk [26]
Communication
Enables sending and receiving messages by using BizTalk Message Queuing (MSMQT).
Receive and send MSMQ messages from and to the MessageBox database.
Enables sending and receiving messages by using SOAP over HTTP (gives BizTalk Server 2004
the ability to interact in a Web services world).
Enables sending and receiving information by using HTTP.
Enables sending and receiving messages by using ANSI X-12 and EDIFACT standards.
Enables exchange of files with FTP servers.
Enables sending messages by using SMTP.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 99 / 244
IP- Project
ATHENA -Project
Document
•
•
•
•
•
•
•
•
•
•
6.2.3
•
•
•
•
•
•
•
•
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Data Integration
Exchanges data with SQL Server database.
Services for combining, accessing, and analyzing operational data through graphical tools.
Automated data mining utilities to discover patterns and spot trends.
Application Integration
Provides a comprehensive list of adapters including SQL Server, Web Services, MQSeries, FTP,
and SAP.
Exists a comprehensive list of adapters for BizTalk partners provide a variety of application- and
technology-specific adapters.
Provides a list of accelerators reduce effort associated with developing and implementing
integrated technology systems (RosettaNet, HIPAA, etc...).
Process Integration
View a single activity instance this shows only the data relevant to the business process the
knowledge worker is concerned with and hides complexity of the heterogeneous implementation.
Browse aggregations (which are key performance indicators) around all the business activities
that are currently being processed or have already happened.
Navigate to the related activity instances such as shipments associated with given purchase
order.
Search for activity instances based on their progress or business data.
TIBCO – ActiveEnterprise [29]
Communication
Support for .NET and Wireless Service.
Full support for Sun's JMS 1.1 specification.
Fully managed .NET API Implementation.
Full support for native and 3rd-party JNDI (Java Naming and Directory Interface).
Support for XA transaction management.
Support for external LDAP user authentication and group information.
Secure messaging with full support for SSL.
Advanced messaging semantics via server-based destination bridging.
•
•
•
•
•
•
Data Integration
Leverages standards and technologies such as XML, J2EE and Web Services.
Easy-to-use design interface that allows for fast deployment and training.
Process templates and out-of-the-box connectivity with leading applications.
Enables reuse of transformation maps.
Graphical data transformation environment.
Adapter supports the major industry-standard databases, including Oracle, DB2, MS SQL Server,
and Sybase.
•
Application Integration
Adapters are available for many applications and platforms including SAP R/3, Siebel,
Peoplesoft, Vantive, Clarify, Lotus Notes, Portal Infranet, Kenan and others.
•
•
•
•
Process Integration
Process management engine designed to meet the needs of organizations that need to handle
extremely high, mission-critical transaction volumes across multiple servers while maintaining the
integrity of individual transactions.
Maps all business processes and to build the integrated enterprise the way in which the
stakeholder community sees the organization.
Enables management to establish and continuously measure Key Performance Indicators (KPIs)
for ongoing process performance and improvement.
Provides direct integration to many of the principal software packages such as SAP, Siebel and
Peoplesoft.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 100 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
webMethods - Integration Platform
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
6.2.4
•
•
•
•
•
•
•
•
•
•
•
Communication
Transport standards such as HTTP(S), FTP and SMTP and message formats such as MIME and
S/MIME.
Data standards such as XML and EDI, as well as custom flat file formats.
Protocols such as SOAP, XML RPC, ebXML and the associated frameworks.
E-business standards such as RosettaNet, UCCnet, SWIFT, and CIDX.
Data Integration
Databases such as Oracle, SQL Server, Informix, Sybase and DB2, as well ODBC- or JDBCcompliant data store.
Legacy CICS- and IMS/TM-based applications.
Application Integration
Commercial applications such as SAP R/3, Siebel, i2, Oracle, and PeopleSoft.
Custom applications written in C/C++, COM, .Net, Java, and EJB.
Adapters interact directly with applications using native Application Programming Interfaces
(APIs).
Provides the underlying support for transporting and encoding business documents using open
standards.
Provide support for e-commerce standards such as EDI, RosettaNet and ebXML.
Process Integration
Innovative business process optimization capabilities (BAM technology).
Enable companies to streamline and fine-tune the processes that incorporate services,
Claim ability to anticipate changes in business activity.
Providing a full set of capabilities for orchestrating both automated and manual processes.
Promoting the creation of business-oriented services that can be reused across different
processes.
Providing a level of abstraction from the underlying systems that makes the task of orchestrating
business processes accessible to the non-technical user.
SeeBeyond – Integrated Composite Application Network (iCAN) [28]
Communication
Communication adapters (e.g. SNA, TCP/IP, etc).
Object oriented technology adapters (e.g. CORBA, Application Servers, etc.).
Messaging (e.g. MQSeries, JMS, MSMQ, etc.).
Web technologies (e.g. HTTP, CGI, etc.).
Screen based integration (e.g. 3270, 5250, VT100, Wise, etc.).
Data Integration
Database access including relational (e.g. DB2, Oracle, etc.), hierarchical (e.g. IMS), network
(e.g. IDMS) and file based (e.g. ADABAS, VSAM, etc.) data sources.
Includes pre-defined support for ebXML as well as other standards like EDI and AS2.
Application Integration
Packaged application adapters using native low level APIs to connect most. efficiently (e.g. SAP,
Peoplesoft, Oracle, etc.).
Provides over 80 packaged adapters that expose JCA and Web services.
Process Integration
Allows to model, test, implement, monitor, manage and optimize business processes that
orchestrate the flow of activities across any number of Web services, systems, people and
partners.
Provides an open graphical modelling environment using BPMN and BPEL4WS.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 101 / 244
IP- Project
ATHENA -Project
Document
6.2.5
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
BEA WebLogic [30]
Communication
Static and dynamic binding to channels.
Channel typing explicitly defines the structure of the message that the channel can route.
Defined channel-naming hierarchy.
Event Generators publish messages to channels from external sources.
Dynamically bind Event Generators to channels at run time.
WebLogic adapters can publish events to channels.
Data Integration
Transformation of data between any of the following input-output data types: XML Data, Non-XML
Data, Java Primitives, and Java classes.
Allows multiple-input sources to a transformation.
Supports complex relations and constraints including joins, unions, and grouping by key fields
Enables transformation of XML grammars.
Enables the transformation of data in a business process using transformations written in XQuery
or XSLT languages.
Transform data received as an incoming message into the business process.
Transform data before the business process sends an outgoing message.
Transform data inside the business process.
Enables creation of metadata to describe non-XML data.
Application Integration
Standards-based architecture for hosting J2EE JCA-based adapters.
Exposed as Application View control in the business process.
J2EE JCA 1.0-based adapter infrastructure with extensions.
Service adapters expose application services to WebLogic Integration.
Event adapters publish asynchronous, unsolicited messages from the application to Message
Broker.
BEA Adapters available for MQ Series, Oracle Applications, PeopleSoft, RDBMS, SAP, and
Siebel applications.
Process Integration
View business activities as services and model business process to orchestrate.
Business process seamlessly interacts with users, applications and back-end. resources, and
resources inside and outside the firewall.
Simplified structured business processes (XML for the flow and Java for the operations).
Graphical business process editing for high-level integration scenarios.
Support for Java code in business process nodes.
Process implementation optimization for performance.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 102 / 244
IP- Project
ATHENA -Project
Document
6.2.6
•
•
•
•
•
•
507849
04.04.05
SAP Netweaver [35]
Communication
Based on a Service Oriented Architecture.
XSLT, JAVA and ABAP based messages reconciliation with SAP Integration Builder.
Data Integration
SAP Master Data Management (MDM) enables companies to store, augment, and consolidate
master data, while ensuring consistent distribution to all applications and systems, working across
heterogeneous systems at multiple locations.
SAP Exchange Infrastructure (XI) enables intersystem communication in a highly heterogeneous,
multivendor technology environment. It provides unique routing execution, queuing and format
conversion capabilities for the secure transport of business data objects.
SAP content integrator (CI) connects business data objects in different systems using object
characteristics and following rules determined by the user.
SAP master data server (MDS) serves as the central processing unit for the handling of master
data across the enterprises.
•
•
Application Integration
J2EE, .NET and obviously ABAP.
Integration with the other SAP products.
•
Process Integration
SAP Exchange Infrastructure (XI) is process-centric.
6.3
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
Survey criteria
Also for the EAI solutions we create an evaluation table to explain differences between tools using
significant criteria. These criteria are:
•
Vendor feasibility: Vendor strength and support.
•
Product architecture: Hub & Spoke, Message Bus, federated, distributed, etc…
•
Adapters: Which software can be pluged to the EAI products.
•
Metadata management: Import, export and management of legacy data.
•
Message protocols: Protocols used to exchange messages.
•
Business Process and workflow support: The capability to model, to design and to integrate
business processes and workflows.
•
Web services enabled: The capability to use SOAP messages and to integrate Web services
•
XML enabled: The capability to support non-proprietary formats based on XML
In the forthcoming tables, we assign for each survey criterion a value from 0 to 3 which indicates
the fulfilling degree:
•
0 – not supported
•
1 – low
•
2 – medium
•
3 – high
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 103 / 244
IP- Project
ATHENA -Project
Document
6.4
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Survey results
IBM
Vendor
feasibilit
y
3
Web
Methods
BEA
2
2
2 - .NET
3 - J2EE
and .NET
2 – J2EE
2 - J2EE
Connecto
r
Architect
ure (JCA)
2Adapters
for some
commerc
ial
enterpris
e
products,
for SQL
server,
MQSerie
s and
Web
services
3Adaptors
for the
main
databas
es and
the main
enterpris
e
platform
s
3Based
on J2EE
JCA and
other
pre-built
adapters
for MQ
Series,
databas
es and
other
enterpris
e
products
3Adapters
for
enterprise
products
and for
custom
application
s written in
C/C++,
COM,
.Net, Java,
and EJB
1Allows
direct
import of
industrystandard
or userdefined
XML
DTDs for
mapping
and
translatio
n
1–
Exists
the
concept
of
metadata
but it is
not
possible
to create
taxonomi
es of
metadata
2Enables
creation
of
metadat
a to
describe
non-XML
data
1 - Ebusiness
standards
such as
RosettaNe
t, UCCnet,
SWIFT,
ebXML
and CIDX
2HTTP,
SOAP,
JMS
2Enables
sending
and
receiving
message
s by
using
BizTalk
Message
Queuing,
SOAP
and
HTTP
Adapter
s
Message
protocol
TIBCO
3
2 - HUB
Product
on J2EE
architect.
Metadat
a
manage
ment
BizTalk
050404_ATHENA_DA31_PartA_V10.doc
3Support
for JMS,
.NET,
SSL,
JNDI and
Ldap
1
SAP
Netweaver
3
See
Beyond
1
3 – J2EE and
.NET
3HTTP(S),
FTP and
SMTP and
message
formats
such as
SOAP,
XML RPC,
ebXML,
MIME and
S/MIME
CONFIDENTIAL
3 - Based
on J2EE
JCA, Web
services
and prebuilt
adapters
for the
most
important
enterprise
products
2 – HTTP,
SOAP
3 - Support
for
Communic
ation
adapters
(HTTP,
SNA),
Object
oriented
technology
adapters
(CORBA
and
Application
server),
Messaging
Page 104 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
IBM
BizTalk
TIBCO
Web
Methods
BEA
SAP
Netweaver
507849
04.04.05
See
Beyond
(MQSeries
, JMS,
MSMQ)
BP and
workflo
w
support
Web
services
enabled
XML
enabled
3Provides
an open
graphical
modelling
environme
nt using
BPMN and
BPEL4WS
2Provides
pre-built
solutions
for
business
process
automati
on and
execution
3–
Graphical
editor of
business
processe
s and
BPEL
suport
3Process
manage
ment
engine
designed
to meet
the
needs of
organizat
ions that
need to
handle
extremel
y high
missioncritical
transacti
on
3Graphica
l
business
process
editing
and
executio
n
platform
3Innovative
business
process
optimizatio
n
capabilities
( BAM
technology
)
3 - Full
Web
services
support
3 - Full
Web
services
support
3 - Full
Web
services
support
3 - Full
Web
services
support
3 - Full
Web
services
support
3 – Full
Web
services
support
3 - Full
Web
services
support
3Supports
optimized
"any-toany"
transform
at
ion of
EDI,
XML, and
recordoriented
applicatio
n data
formats
3 - Full
XML
support
and also
EDI
integratio
n
3 - Full
XML
support
3Transfor
mation of
data
between
XML
Data,
Non-XML
Data,
Java
Primitive
s, and
Java
classes
3 - Full
XML
support
and other
standard
such as
EDI,
RosettaNet
and ebXML
3 – Full
XML
support
3 - Support
for XML
data
manageme
nt
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 105 / 244
IP- Project
ATHENA -Project
Document
6.5
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
The EAI products with ontology tools
Some vendors of mainstream enterprise-application-integration (EAI) solutions are starting to
include in their solutions, and of course also in their marketing material, ontology or more often
taxonomy-related features that are popularly tagged as semantic integration. Vendors like Verity,
Modulant, Unicorn, Semagix, and others are offering platforms to interchange information among
heterogeneous resources including legacy databases, semi-structured repositories, industry-standard
directories and vocabularies like ebXML, and streams of unstructured content as text and media.
•
•
•
•
•
•
•
•
6.6
Semantic integration tools
Verity[18]: The main product is K2 business portal infrastructure that allows semantic search and
retrieval capabilities. The main ability of this product is to manage together information stored in
different applications, such as content management systems, databases, e-mail, file systems and
so on. The software includes complete taxonomy and classification capabilities, an integrated
end-user interface for browsing the knowledge base, a complete reporting and monitoring tool
and a secure access to the shared information.
Modulant[19]: The Contextia Division provides an open and extensible enterprise data platform
that allows organizations to aggregate, validate and visualize their dispersed knowledge of legacy
data into comprehensive, actionable information assets, which support business execution. In
order to realize this challenge, Contextia platform tries to describe what the data is and how it is
used, providing also an innovative data visualization technology.
Unicorn[33]: Unicorn provides two different products to support ontologies.
The first one is Unicorn Coherence that supports ontology modelling and data integration.
The other one is the Unicorn System & Semantic Information Management (SIM) that is a
platform for managing enterprise information assets, including legacy data, databases, and
message formats based on a consistent business understanding of the data. The Unicorn System
provides an environment for managing information assets with integrated capabilities for
metadata management, information modelling, and data semantics. Key elements of the
architecture are Metadata (data assets must be catalogued to be used in different IT project),
Information Model (a rich central model of some or all of the business) and Data Semantics
(semantically mapping data sources to the Information Model to capture meaning).
Semagix[20]: The product is Semagix Freedom that allows information management using a
semantic approach. The figure below shows the architecture of this product.
This architecture is based on different components: A common Ontology designed to represent
knowledge, the Extractor agents to manage relationships with different content sources, a
Semantic Enhancement Server that classifies aggregated content referred to the ontology, an
Automatic Classifier that takes unstructured data as input and classifies it to provide context to
the semantic metadata enhancement process, a Metabase that stores both semantic and
syntactic metadata related to the content, a Semantic Query Server and a Semantic Visualiser
Novell[34]: Novel provides an enterprise storage solution, called NSS, that uses a semantic layer
to help the creation of particular interfaces for accessing the information stored in the system. In
this context Semantic Agents interpret the user queries and translate them into a set of common
layer calls required to execute NetWare file system operations.
Conclusion
From the survey we can understand that the main vendors of the market offer a collection of
complete products that try to solve all the main interoperability issues and support all the new
standards, such as XML, SOAP, BPEL, that help to solve application and data integration problems.
From the last paragraph we can understand also that some minor vendors of the EAI market are
starting to introduce ontologies and a first semantic languages support to cover in particular the data
mapping and transformation process of their products and the data harmonisation. The main vendors
do not seem to support ontologies but in some cases they use taxonomies or glossaries, based on
common standard such as RosettaNet or ebXML, to define a collection of core metadata as main
reference. It could be interesting to understand why the main commercial EAI solutions do not use
ontologies to solve the data mapping issues and if semantic could be the new solution to solve these
kinds of problems. However, Athena should consider the EAI market as a real “competitor” and as the
real State of the Practice in interoperability. The EAI products do not cover all the features that Athena
would implement in its framework and do not reach a perfect efficiency but we have to consider the
fact that the market reports illustrate that the leaders of the market are the vendors which offer a real
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 106 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
integrated, usable and executable framework.
6.7
References
[1]
Conference on ontology tools. Evaluation of Ontology-based Tools Workshop (EON2002) at
the 13th International Conference on Knowledge Engineering and Knowledge Management,
September, 2002 at (http://km.aifb.uni-karlsruhe.de/eon2002/).
[2]
Report on ontology tools. OntoWeb report on a comparative study of 11 ontology editors plus
several other ontology tools, May, 2002 at (http://ontoweb.aifb.unikarlsruhe.de/About/Deliverables/D13_v1-0.zip). “Using WSDL in a UDDI Registry, Version
1.08”. http://www.uddi.org. November 2002.
[3]
Ontology editor survey. http://www.xml.com/2002/11/06/Ontology_Editor_Survey.html,
Michael Denny, O'Reilly Media, Inc. 2002.
[4]
Ontology editors survey, Revisited. Michael Denny,
http://www.xml.com/pub/a/2004/07/14/onto.html, O'Reilly Media, Inc. 2004.
[5]
Comparison of ontology languages. Ontology Overview from Motorola Labs with a comparison
of ontology languages by M. Ribière and P Charlton, December, 2000 at
(http://www.fipa.org/docs/input/f-in-00045/f-in-00045.pdf).
[6]
Ontology-based platform for Semantic Interoperability, from The Handbook of Ontologies in
Information Systems (S.Staab and R.Studer, Eds), M.Missikoff, F.Taglino; Springer Verlag,
2003.
[7]
INTEROP State of the Art Report on Ontology Management and Engineering.
[8]
INTEROP. Deliverable D8.1. State of the art and state of the practice including initial possible
research orientations.
[9]
KAON. Official web site: http://kaon.semanticweb.org/ at Karlsruhe University (D), for
downloading software, tutorials, reference manuals, etc.
[10]
Ontolingua. Official web site. http://www.ksl.stanford.edu/software/ontolingua/
[11]
Protegè 2000. Official web site. http://protege.stanford.edu/ at Stanford University (USA), for
downloading software, tutorials, reference manuals, etc.
[12]
OilEd. Official web site. http://oiled.man.ac.uk/ at Manchester University, for downloading
software, tutorials, reference manuals, etc.
[13]
Metalog. Official web site. http://www.w3.org/RDF/Metalog/
[14]
JENA. Official web site. http://jena.sourceforge.net/JENA. Inference engine.
http://jena.sourceforge.net/inference/
[15]
JESS. Official web site. http://herzberg.ca.sandia.gov/jess/
[16]
SWAP. Official web site. http://www.w3.org/2000/10/swap/
[17]
Commercial Offerings Enabling the Semantic Web.
http://business.semanticweb.org/staticpages/index.php?page=20021016230045730
[18]
Verity. Official web site. http://www.verity.com
[19]
Modulant. Official web site. http://www.modulant.comUnicorn. Official web site.
http://www.unicorn.com
[20]
Semagix. Official web site. http://www.semagix.com
[21]
pOWL. Official web site. http://powl.sourceforge.net
[22]
pOWL. Features and Usage Overview
[23]
pOWL. A Web Based Platform for Collaborative Semantic Web Development. Sören Auer.
University of Leipzig
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 107 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
[24]
EAI tools, Principles & Market Survey, Impact on INTEROP. INTEROP, Luxembourg meeting,
WP 6,7,8,9 Joint Workshop. Chris Sluman. http://www.open-it.co.uk
[25]
IBM – Web Sphere official web site http://www-306.ibm.com/software/info1/websphere/
[26]
Microsoft Biztalk- Official web site. http://www.microsoft.com/biztalk/
[27]
webMethods Fabric. A technical Overview.
http://www.webmethods.com/PDF/webMethods_Fabric_Technical_Overview.pdf
[28]
Seebeyond. Official web site. http://www.seebeyond.com/software/
[29]
Tibco. Official web site http://www.tibco.com/
[30]
Bea. Official documentation web site http://e-docs.bea.com/wli/docs81/index.html
[31]
IBM Ontology-based Web Services for Business Integration.
http://www.alphaworks.ibm.com/tech/owsbi
[32]
KPONTOLOGY. Official web site. http://kpontology.isoco.com/
[33]
Unicorn. Official web site. http://www.unicorn.com/
[34]
Novell. Official web site. http://www.novell.com
[35]
http://www.sap.com/solutions/netweaver/index.epx
[36]
V. Haarslev, R. Möller. Description of the RACER System and its Applications. In Proc. of the
International Workshop on Description Logics (DL-2001), Stanford, USA, 1.-3. August 2001.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 108 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Section III
Ontology Contents
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 109 / 244
IP- Project
ATHENA -Project
Document
7
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Ontology contents
This section of the state-of-the-art describes some of the existing standards and initiatives that
could be used to build a business ontology. It makes sense to build ontologies from such artifacts,
since they represent a consensus, often a very broad one.
The information is structured as follows. First, there is a section showing the relevance of
terminology management to building ontologies. Then there is an overview of the types of business
standards that exist, and some information about the Gefeg database of standards. This is followed by
an overview of some representative artifacts including:
•
Some sources of term definitions like ISO and WordNet
•
Enterprise Modelling Standards ISO 19339 and 19440
•
RosettaNet, an XML-based business framework
•
ebXML, UBL and Core Components
•
The MIT Process Handbook
•
The Supply-Chain Operations Reference Model (SCOR)
Finally, there is a summary and conclusion.
7.1
Terminology Management and Ontologies
Terminology management can provide a model of how to create ontologies and show how existing
material, or content, can be used in their creation. Some background information about terminology
management will help make this clear.
A term is a linguistic expression of a single specific concept from a particular subject field. The
term can take many forms, for example:
FORM
EXAMPLE TERM
single word
machine
multi-word
rear-wheel-drive vehicle
set phrase
night and day
collocation
file a patent (in text the words might not occur together as a phrase)
short form
m (for meter)
boilerplates or standard text, e.g., to represent some terms of a contract
In dealing with concepts, terminology collections are similar to ontologies and different from
dictionaries. This next table shows how a terminology collection differs from a dictionary by showing
the differences between the entries in each (in [12], p. 328).
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 110 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
Lexical Entry
507849
04.04.05
Term Entry
„ Pertains to one word
„ Documents multiple senses of the
„Pertains to one concept
„Documents terms assigned to the
„ Words with same
„One entry for each meaning of a
word (for one etymology)
concept
spelling.(homographic), but with
different derivations in different
entries
term
„Grammar only as related to termconcept assignment
„ Provides grammatical information
pertaining to word
„Systematic concept structure
„ Definition more carefully related to
„ Alphabetic arrangement
„ Definition based on general
other concepts
„Facilitates translation by the
knowledge
ability to relate one concept to the
terms for it in multiple languages
As an example, cardinal, the noun, has one entry in the American Heritage® dictionary with five
senses: a Roman Catholic high church-official, a color, a bird, a cloak and a number. In a terminology
collection, which covered all five senses, there would be five entries, one for each word sense.
The usual process for creating terminologies is directly applicable to creating ontologies. The first
step is to work with domain experts to gather the artefacts that are the source of the terms. These can
range from spoken discourse to handbooks, textbooks, standards, authoritative texts, laws, regulations
and so on. These are the types of ‘content’ that can also serve as input to creating ontologies. Terms
and initial definitions are selected and extracted from these artefacts. In the next step the collected
terms are organized into a concept system, with class and part hierarchies being the most common
systems used. Then, in an iterative process the term definitions and the concept system are refined to
create the terminology collection.
Below is an example of a multi-dimensional concept system, a class hierarchy (in [12], p. 136).
VEHICLE
D3
D1
CARGO
VEHICLE
WATER
VEHICLE
D2
LAND
VEHICLE
AIR
VEHICLE
CAR
NON
MOTORIZED
VEHICLE
PASSENGER
AND CARGO
VEHICLE
MOTORIZED
VEHICLE
PASSENGER
VEHICLE
DIMENSIONS:
D1 BY MEDIUM OF TRANSPORTATION
D2 BY METHOD OF PROPULSION
D3 BY PRINCIPAL TYPE OF LOAD CARRIED
During the process of creating the terminology collection, information about each concept and its
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 111 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
associated terms is recorded.
•
terms that denote the concept, including short forms (synonyms)
•
the preferred term for the concept
•
suggested terms for the concept
•
used but deprecated terms for the concept
•
unequivocal terms for the concept
•
equivocal terms for the concept
•
a classification of each term as being specific to the subject field, borrowed from a related subject
field or taken from general language
•
any standard symbols associated with the concept
This concern with terms is extremely important in a business context as the following quote
shows:
“In the Boeing example [of how to apply Core Components (CC) to a specific problem], the CC is
mapped to the Air Transport Association (ATA) standard. The EDIFACT example in 4.1.5.5
demonstrates how the same CC can be mapped to another message standard format. The mapping
demonstrates that different industries using different terms to represent the same idea make
business communication and data integration difficult. Core Components can be used/reused for
the same data terms/concept defined in different industries (quoted from [11]).” (See Section 7.10 for
more information about Core Components)
Recording this type of information about cross-industry term correspondence can help integration
efforts. Eventually it might also lead to standardization of terms across industries. This would be in line
with the main goal of terminology management, which is to use the same terms for the same concepts
to avoid misunderstandings that waste time and money, and can negatively affect quality. Avoidable
misunderstandings related to product liability and environmental regulations can even result in law
suits and financial losses. Clearly, terminology is of paramount importance in the context of
collaborative business, where a common language or terminology is a prerequisite to successful
collaboration. International collaboration may, in addition, require the use of multiple languages, which
is also facilitated by terminology management.
Other tasks of the process for creating terminologies from artifacts are also applicable to creating
good ontologies. For example, another practice that can be taken over from terminology management
is that if a good definition of a concept already exists, it should be included with a full bibliographic
reference to its source. Example uses of the term should also be included with bibliographic
references.
Yet, another lesson from terminology management is that when creating a terminology collection it
is extremely important to record the subject field to which the terms belong, especially when terms
have multiple meanings, which is often the case. Otherwise, when someone looks up a term in the
collection and gets back multiple entries, it will be very difficult to decide which entry is the desired one.
This principle also applies to ontologies.
Armed with background information about terminology management, it is now possible to move to
the main concern of this section of the document, which is to consider what information can be
extracted from artefacts or ‘content’ and how it might be used. For this purpose the ontology ‘scale’
discussed next is instructive.
Lassila and McGuinness (in [6], pp. 28-29) classified ‘ontologies’ according to the complexity and
formality of the concept-system they represent. The following figure shows this scale, which goes from
simple lists of terms to complex, formalized inter-relationships between terms. This scale represents
the types of information that might be extracted from artifacts. The table that follows and describes the
figure also lists some uses for each type of information.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 112 / 244
IP- Project
ATHENA -Project
Document
Controlled
vocabularies
Formal
is-a
Thesauri
Terms/
glossary
Figure 10.
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
Informal
is-a
Frames
(properties)
Formal
Instance
507849
04.04.05
General
Logical
constraints
Value
Restrictions
Disjointness,
Inverse, Part-of
Types of Ontologies
TYPE
Controlled vocabulary
Description
A list of preferred terms, often with their synonyms. One purpose of
a controlled vocabulary is to standardize descriptive terms in order
to increase the accuracy of search results.
Glossary
A list of terms with definitions specified in natural language. Such a
list is intended to help people understand things.
Thesauri
Thesauri relate terms to each other, usually by listing related terms
under a head term. The set of head terms used in a thesaurus are
commonly organized into a concept system, often represented as a
hierarchy, as in the famous Roget’s Thesaurus. Like controlled
vocabularies, thesauri can be used to improve the search process.
For example, a search system could use the Thesaurus to
substitute related terms or more narrow terms for the user’s search
term. Or the system could suggest that browsing start with broader
terms.
Informal is-a hierarchy
An informal is-a hierarchy organizes terms into broader and
narrower terms that don’t necessarily have a strict class/sub-class
relationship to each other. The Yahoo navigational directories are
examples.
Formal is-a hierarchy
Terms in a formal is-a hierarchy are related by a class/sub-class
relationship.
Formal instance
Formal is-a hierarchy that can include instances.
Frames
Formal is-a hierarchy where the classes also have properties.
With value restriction
Frame systems that allow expression of restrictions on the values of
properties
General logical constraints
The above with the additional capability to express constraints
between terms; constraints are expressed using a form of first-order
logic
Disjointness…
The above with some specific types of term relations like
disjointness, inverse, part-of, etc.
Table 2.
Description of types of ‘ontologies’
As described in the table, even simple, informal term and synonym lists can be used to improve a
search process. At the high end, formal ontologies can add the capability for automation of consistency
checking and even automation of decision making. However, it should also be clear that the features
associated with the low end ‘ontologies’ like terms, natural-language definitions, examples and
synonyms must be included in the high end ontologies. These features are needed for two very
important reasons. First, to enable users to understand the system, and secondly, to enable
developers to understand it in order to make changes.
A mistake made by WordNet (See Section 7.6 for information about WordNet) re-inforces this
view that it is not enough to organize and formalize. As the developers of WordNet discovered, natural
language definitions and examples are indispensable.
(in [4], p. Roman Numeral xx) “As the number of words in WordNet increased, it became
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 113 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
increasingly difficult for us, purely on the basis of synonyms, to keep all the different word
senses distinct. In short, we learned the hard way what any lexicographer could have told us,
namely, that definition by synonymy is not adequate.”
[ Definitions and illustrative phrases and sentences are needed too. ]
…“In the course of incorporating this kind of explanatory information, we have all acquired
greater respect for traditional lexicographers.”
As the example from WordNet shows, terms and their definitions are essential to understanding;
they are equally essential in ontologies for similar reasons. This is just a specific example of the
general thesis that terminology management provides an excellent model for ontology creation.
Applying this model means that like terminologies, ontologies should be based on existing artefacts.
For collaborative business, the artefacts of interest range from glossaries, to classification systems, to
data exchange standards, to business frameworks, to formal ontologies.
One advantage of using existing artefacts is that it leverages the enormous investments, in both
time and resources, which have been made in developing these artefacts. As just one example,
Electronic Data Interchange (EDI) formats like ASC X12, in the United States, have been under
constant development since the 70s. Over 300 X12 messages, or transaction sets as they are called,
have been developed to be used in place of standard paper documents like purchase orders. But this
is just the tip of the iceberg, since these messages are used in industry-specific ways, which are
documented by industry associations in what are called implementation guidelines.
Every message represents a considerable investment of time and effort. For example, it took over
two years to develop The Global Invoice Message (AIAG E-14), a global UN/EDIFACT message for
the automotive industry [5]. Similarly, the recently released Universal Business Language (UBL) 1.0,
which defines XML versions of the documents required for a typical order-to-invoice procurement
cycle, “…represents six years of development in building a standard XML business syntax” .11
However, there are some things that make use of artefacts difficult:
changes over time, e.g., ASC X12 releases updates twice a year and successive releases are
NOT compatible with one another
sheer quantity of artefacts available, just finding the right one to use is difficult
incompatibilities between standards from different sources, e.g. ASC X12, which is used in North
America and UN/EDIFACT, which is used internationally
cultural differences, industry differences
different points of view and different purposes
complexity of the subject matter and the standards (e.g. address standard, see the U.S. Postal
Service reference)
the purpose of the ontology may differ from the purpose of the artefacts
the large number of concepts per artefact means that some automation of ontology creation is
necessary
•
•
•
•
•
•
•
•
The next section gives an overview of some existing types of artefacts that might be useful for
creating business ontologies.
7.2
Overview of types of existing standards and initiatives related to collaborative business
In E-Business Standards by Boris Otto, standards are classified into four areas:
1) product classification, for example:
•
United Nations Standard Product and Services Classification Code UN/SPSC
•
[email protected]
2) exchange of catalogue data, for example:
•
BMEcat
•
xCBL (Common Business Library) from Commerce One
•
cXML (commerce eXtensible Markup Language) from Ariba
•
EDIFACT
3) exchange of business documents, for example:
•
EDIFACT
•
ASC X12
•
openTRANS
11
quoted from http://www.eweek.com/article2/0,1759,1583383,00.asp
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 114 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
•
xCBL
•
UBL
4) and business process integration, which is exchange of business documents in the context of
processes, and includes message exchange protocols.
•
RosettaNet
•
BizTalk from Microsoft
•
ebXML – ASC X12 is collaborating in the development of ebXML, which is a cross-industry
standardization effort to develop a common framework for XML business messages.
•
UN/Business Collaboration Framework www.unbcf.org
These categories from Boris Otto can be extended with others:
1) Directory-related formats, for example:
•
UDDI (not covered in this survey)
•
trading partner agreements from ebXML (not covered in this survey)
2) Enterprise Modelling Language Contructs like those defined in ISO 19339 (methodology) and ISO
19440 (contructs)
3) the STEP standard, ISO 10303, for the exchange of technical product data (Although, this is a very
important standard, it is not covered in this survey, since the survey focuses more on generic
business aspects than technical aspects like detailed product data and 3-dimensional design
models.)
4) Reference models like SCOR
5) Knowledge bases like the MIT Process Handbook
A striking feature of standardization is that it is very industry specific. So, for example, there are
general product classification standards like UN/SPSC and [email protected], but the German electronics
industry has developed their own classification system called ETIM. This babelization or proliferation of
dialects is wide-spread and appears to be endemic.
Boris Otto’s E-Business Standards brings out another notable fact about standardization. Its
survey results, covering the German electronics industry and German electronics wholesalers, show
that the most widely used transaction standard in these industries is EDIFACT, which is used by
43.4% of the surveyed companies. XML-based transaction standards are little used. cXML at 3.8%
was the most widely used as of August 2002. The dominance of classic EDI standards is confirmed by
the ASC X12 web site, where is says that “more than 300,000 companies worldwide use the X12
electronic data interchange (EDI) standards in daily business transactions.” 12 ASC X12 continues to
support and develop these older standards, while at the same time working on XML business message
standards.
In addition to classic EDI standards, there are hundreds of XML applications or initiatives. Long
lists can be found at the web sites http://xml.coverpages.org/xmlApplications.html and www.xml.org .
7.3
Database of B2B documents - GEFEG
GEFEG is a B2B consulting company that has a comprehensive database of the most widely used
B2B documents. For example, their specialized database contains all existing UN/EDIFACT and ANSI
X12 message types, segments, composite data elements and codes. As XML has come into use, the
database has been extended with XML-based standards like OAGIS, RosettaNet, XBRL, xCBL and
UBL. In addition, the database covers proprietary standards like SES (Siemens EDIFACT Standard),
Philips COPS and SAP IDocs.
The main product of GEFEG is a tool called GEFEG EDIFIX® that is used in combination with the
database to speed up the implementation of B2B processes. A major use of this tool is to tailor a
generic standard document to a specific use and to document this use in an implementation guideline.
For example, according to GEFEG:
“Taking xCBL V3.0 as an example, the ORDER allows more that 20,000 elements. It is only due
to the implementation guideline that it is possible to specify which elements are actually used in
the data exchange of business partners.” 13
The process of tailoring standard documents is often multi-level. An industry group defines and
12
13
quoted from http://www.x12.org/x12org/about/X12Strategy.cfm
Quoted from http://www.gefeg.com/en/edifix/xml-spy.htm
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 115 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
documents a “subset” for use in that industry. Then a company in that industry further refines and
documents the industry subset, which refinement, in turn, might be fine-tailored for use in a specific
process.
The implementation guidelines created in each case, with their definitions and annotations, are the
basis for interpreting the exchanged documents and mapping them to in-house formats. Moreover,
they can be used to generate program artifacts like XML schemas, database tables, text messages,
Web Forms, etc.
To be more syntax neutral in the development of data models GEFEG EDIFIX® now includes a
UML Class editor from which the desired syntax-specific “schema” and guideline can be derived.
Some important features of this are:
•
design is modular; in future Core Components and Business Information Entities will be
integrated;
•
syntax neutrality, the end format can be an XML format like xCBL or a classic EDI format
like UN/EDIFACT;
•
compliant with UN/CEFACT Modeling Methodology (UMM);
•
version management;
•
automatic derivation of a glossary.
Application of ontologies to the problem of data modeling in e-business should have as its starting
point the investigation of the value-add that ontologies can have for tools like GEFEG EDIFIX®, since
they represent the state-of-the-art.
7.3.1
Overview of GEFEG – copied from their web site:
“GEFEG mbH was founded in Berlin in 1990 and has been growing continuously since then. The
installed base of about 750 national and international customers include major companies as well as
non-profit organizations aiming at the facilitation of international trade. GEFEG is an active member of
B2B standardization organizations, like EDIFICE (Europe), DISA (USA), DIN (Germany).
•
•
•
•
•
•
•
7.4
GEFEG's consultants have been working for major B2B projects worldwide and across Europe.
Advisor to the German Chairman of the G7 Customs Group
Advisor to the Joint Automotive Initiative's Global Invoice Project, a joint initiative of AIAG (USA),
JAMA/JAPIA (Japan) and ODETTE (Europe)
Development of xCBL® based implementation guidelines for the cc-chemplorer market place (
chemical industry )
Advisor to the German EDI Association (DEDIG)
German delegate to the UN/CEFACT EDIFACT Directory Audit Team
Active involvement in the development of ISO/TS 20625 "Rules for generation of XML schema
files on the basis of EDI(FACT) implementation guidelines"
Member of EDIFICE's "SAP Integration" and "Technical Support & Quality Assurance" task
groups; contributions to "Self-Billing" task group “
ISO Standards as a source of terminology
ISO standards are a good source of terminology. Just as an example, below is an extract from the
vocabulary standards under the subject heading of Road vehicle engineering (Vocabularies). More
lists of vocabularies can be found under the International Classification for Standards (ICS) heading
01.040 Vocabularies.
•
ISO 611:2003 Road vehicles -- Braking of automotive vehicles and their trailers -- Vocabulary
•
ISO 612:1978 Road vehicles -- Dimensions of motor vehicles and towed vehicles -- Terms and
definitions
•
ISO 1176:1990 Road vehicles -- Masses -- Vocabulary and codes
•
ISO 3536:1999 Road vehicles -- Safety glazing materials -- Vocabulary
•
ISO 3833:1977 Road vehicles -- Types -- Terms and definitions
……
•
ISO 11841-2:2000 Road vehicles and internal combustion engines -- Filter vocabulary -- Part 2:
Definitions of characteristics of filters and their components
•
ISO 12353-1:2002 Road vehicles -- Traffic accident analysis -- Part 1: Vocabulary
•
ISO 14722:1998 Moped and moped-rider kinematics -- Vocabulary
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 116 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Vocabularies are often part of a series of standards as for example in this next series, where
Part 2 lists terms etc.
ISO 15031-1:2001 Road vehicles -- Communication between vehicle and external equipment for
emissions-related diagnostics -- Part 1: General information
ISO/TR 15031-2 Road vehicles -- Communication between vehicle and external equipment for
emissions-related diagnostics -- Part 2: Terms, definitions, abbreviations and acronyms
ISO 15031-3:2004 Road vehicles -- Communication between vehicle and external equipment for
emissions-related diagnostics -- Part 3: Diagnostic connector and related electrical circuits,
specification and use
ISO/DIS 15031-4.3 Road vehicles -- Communication between vehicle and external equipment
for emissions-related diagnostics -- Part 4: External test equipment
ISO/DIS 15031-5.4 Road vehicles -- Communication between vehicle and external equipment
for emissions-related diagnostics -- Part 5: Emissions-related diagnostic services
ISO/DIS 15031-6.4 Road vehicles -- Communication between vehicle and external equipment
for emissions-related diagnostics -- Part 6: Diagnostic trouble code definitions
ISO 15031-7:2001 Road vehicles -- Communication between vehicle and external equipment for
emissions-related diagnostics -- Part 7: Data link security
•
•
•
•
•
•
•
Example of a definition from an ISO Standard as quoted in SCOR
Product: The end object of a transformation process that includes physical objects,
information or services. "Result of activities or processes and may include service,
hardware, processed materials, software or a combination thereof; can be tangible (e.g.
assemblies of processed materials) or intangible (e.g. knowledge or concepts) or a
combination thereof; can be either intended (e.g. offering to customers) or unintended (e.g.
pollutant or unwanted effects)."[1]
[1] ISO 8402:1994 Quality Management and Assurance – Vocabulary, Geneva Switzerland,
International Organization for Standardization.
7.4.1
ISO Standards related to terminology management
A number of ISO standards deal with terminology management:
ISO 704 – Principles and methods of terminology
ISO 860 – Terminology work – Harmonization of concepts and terms
ISO 10241 – International terminology standards – Preparation and layout
ISO 1087 – Terminology - Vocabulary
ISO/DIS 15188 – Project management guidelines for terminology standardization
•
•
•
•
•
7.4.2
Short Description of ISO
ISO (International Organization for Standardization) is a network of the national standards
institutes of 148 countries, on the basis of one member per country.
“To date, ISO's work has resulted in some 12 000 International Standards, representing more
than 300 000 pages in English and French (terminology is often provided in other languages
as well.)”14
7.5
Enterprise Modelling: ISO 19439 and ISO 19440 Standards
These standards are intended to provide a common understanding, terminology and language
constructs related to Enterprise Modelling. Intended users of the constructs are business users, who
will use them to model business requirements, to create decision-support models, and to create
models for operation and control purposes.
Although these ISO standards are part of a series related to Computer-Integrated Manufacturing
(CIM), they are applicable to Enterprise Modelling in general, and define both a methodology and a set
of informal language constructs for multi-view Enterprise Modelling. The views covered are: Function,
Information, Resource and Organisation, defined as follows in ISO 19439:
•
function view to represent the processes and activities of the enterprise,
•
information view to represent the enterprise information used and obtained during the operation,
14
Quoted from http://www.iso.org/iso/en/stdsdevelopment/whowhenhow/how.html
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 117 / 244
IP- Project
ATHENA -Project
Document
•
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
resource view to represent the enterprise assets needed for carrying out the enterprise
operations, and
organization view to represent the organization, organizational relationships and the decision
making responsibilities in the enterprise operation.
•
The standards adopt a process-oriented modelling approach with the aim to produce operational
process monitoring and control models that ultimately can be used to monitor and control the daily
operations of an enterprise.
The four Views defined by the standards are considered to be one dimension out of three. The
other two are the Life-cycle Phase and ‘Genericity’. ‘Life-cycle Phase’ refers to the phases of
enterprise model development. There are seven phases starting with identification and ending with
decommissioning of the enterprise domain model. The four enterprise model views and three levels of
genericity need to be considered at each of these seven enterprise model phases. ‘Genericity’, refers
to the idea of creating generic constructs that can be specialized for particular industries or purposes
such as maintenance.
7.6
WordNet as a source of terms and taxonomy
Another potential source of terms and even taxonomies for general English is WordNet. WordNet
is an electronic lexical database of English, which was created by hand. WordNet has been used in
numerous projects in Natural Language Processing and Artificial Intelligence. Having been under
development since the ‘80s, it now has a coverage comparable to the popular Meriam-Webster®
dictionary. But, it is organized along entirely different lines. Rather than being arranged alphabetically
by word, it is a network of lexical and semantic relationships, which means relationships directly
between words, and relationships between the meanings of words, respectively. The most important
relation for WordNet is similarity of meaning.
Meanings or concepts in WordNet are represented by sets of words with essentially the same
meaning, that is, synonyms. These sets are called synsets. This is another interesting contrast with
standard dictionaries, in which the point is to distinguish between the often subtle shades of meaning
of synonyms. It is doubtful that any synset fully passes the synonym test attributed to Leibnitz: a word
is a synonym of another if replacing it in a sentence does not change the meaning of the sentence.
Nonetheless, WordNet seems to have resolved this problem well enough to have been useful in a
number of IT projects.
In WordNet the different categories of words: nouns, verbs, adjectives and adverbs are organized
in different ways. Noun synsets are organized into a taxonomy, which essentially means a class
hierarchy. An extract of a hierarchy is shown next. Curly brackets enclose synsets. The symbol @->
denotes is-a-kind-of.
{robin, redbreast}@->{bird}@->{animal, animate_being}@->{organism, life_form, living_thing}15
In addition to being organized taxonomically, nouns can be structured into part/whole hierarchies if
applicable. A less fundamental, but interesting relationship between nouns, is that of antonymy,
meaning opposition. Victory and defeat are antonyms.
Verb synsets are also organized into hierarchies based on a few relationships like troponymy,
meaning way or manner. To march is a troponym of to walk because marching is a way or manner of
walking.
Adjectives have a rich organizational structure based on antonymy and similarity, and adverbs are
linked to adjectives from which they are derived.
An example of a WordNet entry is given next.
The noun "board" has 9 senses in WordNet.
1) board -- (a committee having supervisory powers; "the board has seven members")
2) board -- (a flat piece of material designed for a special purpose; "he nailed boards across the
windows")
3) board, plank -- (a stout length of sawn timber; made in a wide variety of sizes and used for many
purposes)
4) display panel, display board, board -- (a board on which information can be displayed to public
15
Example from [4] p. 25.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 118 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
view)
5) board, gameboard -- (a flat portable surface (usually rectangular) designed for board games; "he
got out the board and set up the pieces")
6) board, table -- (food or meals in general; "she sets a fine table"; "room and board")
7) control panel, instrument panel, control board, board, panel -- (electrical device consisting of an
insulated panel containing switches and dials and meters for controlling other electrical devices;
"he checked the instrument panel"; "suddenly the board lit up like a Christmas tree")
8) circuit board, circuit card, board, card -- (a printed circuit that can be inserted into expansion slots
in a computer to increase the computer's capabilities)
9) dining table, board -- (a table at which meals are served; "he helped her clear the dining table"; "a
feast was spread upon the board")
Sense 1 is a specialization of the synset {committee, commission}
board -- (a committee having supervisory powers; "the board has seven members") => committee,
commission -- (a special group delegated to consider some matter; "a committee is a group that keeps
minutes and loses hours" - Milton Berle)
7.7
RosettaNet
RosettaNet, a subsidiary of the Uniform Code Council, Inc.® (UCC®), is a non-profit consortium
developing standards for an XML-based e-business framework. Currently its members are from the
high-tech industry, but there are plans to extend membership to adjacent industries such as logistics,
consumer electronics and aerospace. RosettaNet standards and supporting materials are freely
available to the public at their web site, www.rosettanet.org. These standards encompass: dictionaries;
an implementation framework for secure message transfer, routing and packaging; XML-based
business message schemas and process specifications, all of which have been proven by production
implementations by member companies. RosettaNet also offers services like partner discovery.
RosettaNet has identified four basic XML-related components needed to conduct e-business
within a single supply chain16:
•
Messaging Service
•
Business Dictionary Structure and Content (of messages)
•
Technical Dictionary Structure and Content (of messages)
•
Business Processes (content and choreography)
RosettaNet covers all of these four components for high-tech supply chains. Messaging is covered
by the RosettaNet Implementation Framework (RNIF). The RosettaNet Business Dictionary describes
properties related to business transactions, and the RosettaNet Technical Dictionary describes
properties related to products and services.
A RosettaNet process is called a Partner Interface Process® (PIP®). A PIP® specifies the
choreography of the message dialogues between trading partners and the vocabulary of the
exchanged business documents. Processes in RosettaNet are categorized into the following clusters:
•
RosettaNet Support, Administrative functions
•
Partner, Product and Service Review
•
Product Information
•
Order Management
•
Inventory Management
•
Marketing Information Management
•
Service and Support
•
Manufacturing
E-business between supply chains, having as it does a larger scope than e-business within just
one supply chain, requires more components, as well as more generic or universal components:
•
Universal Messaging Service
•
Universal Registry and Repository Structure
•
Universal Business Dictionary Structure and Content (of messages)
16
From
http://www.rosettanet.org/RosettaNet/Doc/0/9QJUBA4T9U04L8LQONLEHFDM8C/Standards+Conver
gence+White+Paper.pdf
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 119 / 244
IP- Project
ATHENA -Project
Document
•
•
•
•
•
•
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Universal Technical Dictionary Structure and Content (of messages)
Universal Business Processes (content and choreography)
Business-model-specific business processes
Supply Chain Technical Dictionary Content
Supply Chain Business Processes
Universal Specification Schema and Architecture
RosettaNet evaluated its own efforts against this list and noted that the only area in which it is not
active is the Universal Registry, so that RosettaNet decided to support UDDI for the electronic
registration and discovery of trading partner relationships. It will also support the ebXML registry and
repository if it becomes widely accepted. Trading Partner Agreements (TPA) are also part of the
registry component, and specify the terms and conditions of a trading partner relationship.
RosettaNet is a subsidiary of The Uniform Code Council
About the Uniform Code Council – as copied from a press release
“The Uniform Code Council, Inc. ® (UCC®) is a not-for-profit organization dedicated to the
development and implementation of standards-based, global supply chain solutions. Under its
auspices, the UCC operates three subsidiaries, UCCnet™, RosettaNet, and EPCglobal US™ and it
co-manages the global EAN•UCC System with EAN International. The UCC also manages the United
Nations Standard Products and Services Code (UNSPSC®) for the United Nations Development
Programme (UNDP). The newly formed EPCglobal Inc is a joint venture of the Uniform Code Council
and EAN International. UCC-based solutions, including business processes, XML standards, EDI
transaction sets, and the bar code identification standards of the EAN•UCC System are currently used
by more than one million member companies worldwide. For more information about the Uniform
Code Council, please visit: www.uc-council.org.”
7.8
ebXML
Like RosettaNet, ebXML specifies an entire e-business framework.
http://www.ebxmlforum.org/articles/ebfor_SoftwareProducts.html
7.9
Universal Business Language (UBL)
UBL V1.0, released in May 2004, defines XML schemas for common business documents. This
first version covers the documents needed for the order-to-invoice cycle. Other types of documents will
be added over time. The ultimate goal of UBL is to replace the multiplicity of XML standards for
common business documents with one de-facto standard, UBL, thereby reducing integration time and
costs. UBL covers the most common data elements used in business, but has to be customized or
extended for particular industries.
UBL is designed for use in standard business frameworks such as ISO 15000 (ebXML), and is an
implementation of the ebXML Core Components Technical Specification (CCTS) 2.01. In line with the
philosophy of CCTS, UBL is built on a library of components like Address, Item, and Payment.
Business documents like Order and Invoice are assembled from these components. The initial UBL
library of data components was based on xCBL 3.0, which was itself based on the UN/EDIFACT and
ASC X12 EDI component libraries. To facilitate modification, customization and understanding, UBL
created an abstract conceptual model of these components.
Documents are also modeled conceptually using spreadsheets. UBL’s Naming and Design Rules
specify how to transform these spreadsheet conceptual models into W3C XSD schema syntax. In
addition to conceptual models of components and documents the UBL 1.0 release contains other
supporting materials such as:
•
Unified Modeling Language (UML) class diagrams of components and documents
•
sample instances
•
formatting specifications for layout of elements, e.g., for printing
•
scenarios and related business rules
•
guidelines for customization
•
pointers to supporting tools like GEFEG EDIFIX® 5.0, which is used to generate the schemas
from the spreadsheet models.
•
Alternative schema definitions for encoding documents in accordance with ITU-T X.680-X.693
(ASN.1), for use when an efficient binary encoding is needed
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 120 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Work on UBL is on-going. One of the work items planned for UBL 1.1 is to align the CCTS
schemas of UBL with those from the Open Applications Group, Inc. A number of differences between
UBL 1.0 and OAGIS 9.0 have been identified.
UBL was developed by volunteers working under the umbrella of OASIS, a non-profit corporation
dedicated to the adoption of structured information standards. It is available free of charge. Its
developers expect it to be used at first by government procurement agencies, which are expected to
use open-source ebXML and UBL implementations. The Danish government, for example, is said to
be
adopting
UBL.
For
more
information
about
UBL
see
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=ubl
7.10 Core Components – part of the ebXML Framework
The idea of Core Components was developed as part of the ebXML Framework, and is a new
approach to solve the problem of data interoperability in e-business. It specifies a method to develop
re-usable building blocks that represent the data commonly used in business today. Such building
blocks, or components, range in size from generic data-types to whole business documents like
purchase orders.
•
•
•
•
•
•
The goals to be achieved by using Core Components are:
to standardize data across industries and internationally
to re-use standardized data, extending it as needed
to use internationally-maintained registries of data to support re-use, extension and
harmonization across industries and cultures
to be independent of syntax, and, at the same time, to enable bindings to commonly used
syntaxes like EDIFACT and XML
to be useful for application-to-application communication, e.g. web services, and application-tohuman communication; e.g., forms to enter data could be automatically generated from
descriptions of components.
to facilitate localization for different countries and languages
In summary, the ebXML Framework envisions industry communities collaborating to develop reusable building blocks that are made available in internationally-managed repositories. Key elements
of this vision are:
•
using naming rules, definitions and business terms to document the meaning of business data
•
using context and qualifiers to more precisely specify the meaning of business data
A qualifier is a “word or phrase that qualifies, limits, or modifies the meaning of another word or
phrase.”17)
•
using a well-defined set of data types as the basis for representing data values
The combination of naming rules, definitions, business terms, context and qualifiers facilitates the
process of finding and re-using components in repositories.
•
•
•
•
•
The rest of this section explains the basic concepts of Core Components, covering:
core components which are generic types of components
core-components types which specify the representation of data values
business information entities which are based on core components, and have a business
meaning, also called business semantics
context which is an essential factor in business meaning
processes for discovering, re-using, extending and adding components to repositories
The explanation which follows is based on The Core Components Technical Specification (CCTS)
and The CCTS User’s Guide.
17
All definitions in this section come from [1].
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 121 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
Work Address
Person
507849
04.04.05
Address
Street: Text
City: Text
State: Code
Person ID: Identifier
First Name: Text
Last Name: Text
Home Address
Figure 11.
UML class diagram of components
7.10.1 Explanation of Core Components
Core Components (CC) are the standardized elements used for constructing electronic data and
documents. There are three types of CCs corresponding to the three types of things represented in the
example Unified Modeling Language (UML) Class diagram shown above:
•
An Aggregate Core Component (ACC) represents an object class like Person or Address
•
A Basic Core Component (BCC) represents an object-class property (attribute) whose value type
is a data type, e.g., Person. Person ID. Identifier, where Identifier is the data type.
•
An Association Core Component (ASCC) represents an object-class property whose value type is
an object class; e.g., Person. Work Address. Address (strictly speaking, this ‘property’
corresponds to the role of the association in the UML diagram)
A data type is represented by a Core Component Type (CCT) which defines the type of
information that a BCC may contain, e.g., identifier, text, code, date, monetary amount, etc.
Each CC is given a unique name by which it can be found in the registry or “dictionary”, hence this
is called its Dictionary Entry Name. The previous UML diagram is used below to show how unique
names of Core Components are formed. The rules for their formation are based on ISO 11179.
The example diagram has 2 Aggregate Core Components: Person. Details and Address. Details.
It has 2 Association Core Components: Person. Work. Address and Person. Home. Address. And, it
has 6 Basic Core Components, e.g., Address. Street. Text
Person. Details
Person. Person ID.
Identifier
Person. First Name.
Text
Person. Last Name.
Text
Figure 12.
Person. Work. Address
Address. Details
Address. Street. Text
Address. City. Text
Address. State. Code
Person. Home. Address
Names of core components
This example illustrates the basic rules for constructing unique names. ACCs are named by
appending a dot, a space and the word ‘Details’ to the object class name. ASCC names are formed by
concatenating the object class name, the property name and the object class name corresponding to
the value of the property. This example also shows a use of the truncation rule which allows the
elimination of redundant words, so that instead of the name ‘Person. Work Address. Address’, we get
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 122 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
‘Person. Work. Address’. BCC names are formed by concatenating the object class name, property
name and representation term. Representation terms correspond to Core Component Types, which
are also stored in the registry.
7.10.2 Core Component Types
The CCTS restricts types and representation terms to those listed in the next table. In naming a
BCC, either the primary or a secondary representation term may be used. Whichever is more accurate
should be preferred.
As shown, the dictionary entry names for Core Component Types are formed by appending ‘.
Type’ to the type name. These types are not primitive types. Each type has a content component and
one or more supplementary components that specify how to interpret the content. Content is of some
primitive type. As an example, Text. Type has the following components:
•
Text. Content: the character string, usually a natural language string
•
Language. Identifier: the natural language of the string
•
Langauge. Locale. Identifier: the place where the natural language is spoken
Similarly, the other types also have a content component and supplementary components, e.g., a
monetary amount has currency in a supplementary component. In many cases, the CCTS prescribes
the use of a specific standard code-set in the component of a data type.
Core Component Type
Primary Representation Term
Amount. Type
Binary Object. Type
Code. Type
Date Time. Type
Identifier. Type
Measure. Type
Numeric. Type
Quantity. Type
Text. Type
Amount
Binary Object
Code
Date Time
Identifier
Measure
Numeric
Quantity
Text
Secondary Representation
Term
Graphic, Picture, Sound, Video
Date, Time
Value, Rate, Percent
Name
In the registry each CC must have a unique definition. Synonomous business terms can also be
put in the registry for each CC, although the usefulness of this depends on being able to also note in
which contexts the terms are really synonyms.
One key to CCTS is to carefully name and define building blocks, so that they can be found for reuse. As already shown in this section, nomenclature starts with the most basic building blocks, the
data types, e.g., types like Text.
7.10.3 Business Information Entities
The CCs are generic components. Actual business documents are composed of Business
Information Entities (BIE), which are CCs which have been given a business context using the
standard CCTS context categories explained in the next section. Just as there are three types of CC,
so there are three corresponding types of BIE as shown in the table below.
Core Component Type (CC)
Aggregate CC (ACC)
Basic CC (BCC)
Association CC (ASCC)
Business Information Entity Type (BIE)
Aggregate BIE (ABIE)
Basic BIE (BBIE)
Association BIE (ASBIE)
Qualifiers and data typing play a major role in the definition of BIEs.
For example, if an
application exchanges data about people from the United States, the BIE name can be created by
qualifying the CC name using the qualifier “US_’ as shown in the next figure. Not shown in the figure
are the dictionary entry names for the data types, e.g., US SSN_ Identifier. Type. These must also be
defined, in terms of constraints on CCTs, and entered in the registry. Constraints can extend or restrict
a CCT or specify facets (a facet is a constraint on the values of a property), e.g., the cardinality of a
property value or minimum or maximum values.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 123 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
All qualifiers are shown as ending with an underscore and a space. If they are multi-word, there is
a space between the individual words. The example below does show BIE names with qualified data
types, like ‘US SSN_’, which stands for US social security number.
US_ Person. Work. US_
Address
US_ Person. Details
US_ Person. Person ID.
US SSN_ Identifier
US_ Person. First Name.
Text
US_ Person. Last Name.
Text
Figure 13.
US_ Address. Details
US_ Address. Street. Text
US_ Address. City. Text
US_ Address. State.
US State_ Code
US_ Person. Home. US_
Address
Names of business information entities
7.10.4 Summary table for CCTS
The next table summarizes the correspondence between UML Class constructs, Core
Components and Business Information Entities. In addition, the last row shows the correspondence
between the various data types.
UML construct
Object Class
Core Component Type (CC) and
example names
Aggregate CC (ACC)
Person. Details
Association between two
classes
Association CC (ASCC)
Person. Work. Address
Attribute/Property
of Class
Basic CC (BCC)
Person. First Name. Text
Data Type of Attribute
Data Type of BCC, which must be
based on a Core Component
Type
Business Information Entity
Type (BIE) and example names
Aggregate BIE (ABIE); An ABIE
must be based on an ACC, and
may be qualified.
US_ Person. Details
Association BIE (ASBIE); An
ASBIE must be based on a
ASCC, and may be qualified.
US_ Person. Work. US_ Address
Basic BIE (BBIE); A BBIE must be
based on a BCC, and may be
qualified.
US_ Person. Person ID. US SSN_
Identifier
Data Type of BIE, which must be
based on a Core Component
Type, and may be qualified.
7.11 Context
Context is extremely important since the meaning of terms and the relationships between terms
depends on it. Context in CCTS is comparable to the term subject field in terminology management.
In CCTS, Context is specified by assigning values to the context categories defined by The CCTS.
The next table is based on information from the UNCEFACT – Core Components User’s Guide and
the UN/CEFACT Core Components Technical Specification and shows the eight context categories
currently identified.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 124 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
One purpose of context is to enable BIEs to be derived from CCs by specifying the context of the
BIE. For example, if buyer address can be used in any process in any industry in the United States,
then the context associated with it would be:
Business Process = in all contexts
Product Classification = in all contexts
Industry Classification = in all contexts
Geopolitical = United States
Official Constraint = none
Business Process Role = in all contexts
Supporting Role = in all contexts
System Capabilities = in all contexts
Context Category
Business Process
Product Classification
Industry Classification
Geopolitical
Official constraints
Business Process Role
Supporting Role
System Capabilities
Description
The business process name.
It is intended that names
come from the UN/CEFACT
Catalogue of Common
Business Processes.
The type of products
involved in the business
process, where ‘products’
can be material or
immaterial, e.g., services.
The industry or sub-industry
in which the business
process takes place.
The locations of the
participants in the business
process
Legislation and regulations
that apply to the business
process
The roles played by the main
participants in the business
process. Like process
names, the role names come
from the UN/CEFACT
Catalogue.
Supporting roles involved in
the business process.
‘Supporting’ means the role
influences the data
exchanged, but is not itself
involved in data exchanges
in this business process.
Identification of a specific
type of system, e.g., an ERP
system. This is necessary if
the system, e.g., requires
extra information in the
context of the business
process
Example Values
Ordering
Delivery
Parts
Consumer goods
Consulting services
Aerospace
Fast Moving Consumer Goods
International
Europe
US law
EU law
Buyer
Seller
Shipping Agent
EAN.UCC system
SAP
The CCTS identifies some standards that can be used in assigning values to the context
categories as shown in the next table.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 125 / 244
IP- Project
ATHENA -Project
Document
Context Category
Business Process
Product Classification
Industry Classification
Geopolitical
Official constraints
Business Process Role
Supporting Role
System Capabilities
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Relevant Standards
UN/CEFACT Catalogue of Common Business Processes (work in
progress)
Universal Standard Product and Service Specification (UNSPSC),
maintained by Electronic Commerce Code Management
Association (ECCMA)
Standard International Trade Classification (SITC Rev .3),
maintained by United Nations Statistics Division (UNSD)
Harmonized Commodity Description and Coding System (HS),
maintained by World Customs Organization (WCO)
Classification of the purposes of non-profit institutions serving
households (COPI), maintained by UNSD
International Standard Industrial Classification (ISIC), maintained
by UNSD
UNSPC top-level segment used to define industry
others codes may also be used
Special structure that uses ISO 3166.1 for country codes and ISO
3166.2 for region codes.
There is no known global classification system for this
Role values from the UN/CEFACT Catalogue of Common
Business Processes
UN/EDIFACT Code List for DE 3035 Party Roles
There is no known global classification system for this
UNSD provides a mapping between the first three product classification systems.
7.11.1 Processes associated with core components
The CCTS specifies in detail the processes associated with using, extending, updating, and
harmonizing registries of core components. In basic outline, the major steps associated with re-using
the Core Components are:
1) model a business process using a standard method like UMM
2) based on the process, derive the UML class diagrams for the data to be exchanged
3) search the registries for similar re-usable information building blocks, first BIEs then CCs
4) Register re-use if applicable, otherwise extend existing components or develop new components
for eventual inclusion in the registry
For details of processes and procedures see the CCTS.
7.12 MIT Process Handbook
The MIT Process Handbook, which is available on-line, is a knowledge base of business
processes and practices, as well as a set of tools for navigating and organizing the knowledge base.
The Handbook has been in development by the MIT Sloan School of Management since 1991, and
currently contains over 5000 process entries. Development of the Handbook is continuing in an “opensource” initiative called The Open Process Handbook Initiative (OPHI) (ccs.mit.edu/ph).
The main purpose of the Handbook is to aid people in organizing process knowledge in order to
find it, use it, re-design processes and invent new processes. A further potential use of the Handbook
is to automatically or semi-automatically generate software to support or analyze processes.
Organization of process knowledge in the Handbook is based on two key concepts: specialization
and coordination. Specialization is used to organize processes into generalization/specialization
hierarchies. For example, Sell via store is a specialization of Sell how. Within a hierarchy processes at
the same level are often bundled according to which question they answer, e.g., who, what, where,
why, when or how. Processes that answer the same question, like Sell via store and Sell via face-toface sales, are in the same bundle, in this case, the Sell how bundle. Trade-off matrices comparing
cost, time, quality, and so on, can be included in the Handbook to help people to choose among such
alternative processes. In addition to being organized in a hierarchy, processes in the Handbook can
also be decomposed into sub-processes, although rather informally since the intent is not to specify
control flow, but only to show the sub-processes — or parts as the Handbook calls them — that make
up the process.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 126 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Coordination is the second key concept used to organize the Handbook. A coordination process is
a way to manage dependencies between activities, where activity is a synonym for process. Such
dependencies usually involve both activities and resources. Three basic types of dependencies have
been identified:
•
Flow
•
Sharing
•
Fit
A flow dependency is very common and occurs when a resource flows from one activity to another
activity. For example, parts in a factory flow from work station to work station. There are three aspects
to flow dependency: prerequisite, accessibility and usability. These refer respectively to having the
resource at the right time, the right place, and, finally, having the right resource. A sharing dependency
occurs when multiple activities all need the same resource, for example, two activities need to use the
same machine on the factory floor. A fit dependency occurs when several activities have to fit together
to create one resource, e.g., the several design activities for the various parts of a truck.
Coordination processes are included in the Handbook so that people can find and consider
alternative ways of managing coordination. This is a variation on the general purpose of the Handbook,
which is to organize process-related knowledge in order to be able to find it, use it, re-design it and
invent new processes.
Athena might consider using some of the organizational ideas and content from the MIT
Handbook to start a handbook of cross-company collaborative processes that can be used to speed up
and improve the design of B2B inter-actions. This handbook could also be used to organize and
maybe even generate software related to these processes. A software architecture based on such a
handbook could relate software components to low-level processes and software connectors to
coordination processes. These software connectors might, in some cases, use agent-based software.
7.13 SCOR
7.13.1 SCOR – source of information
All information in this document about SCOR is based either directly or indirectly on material from
the Supply Chain Council, which develops the SCOR model. For more information about SCOR see
the excellent introduction in the SCOR 6.0 Overview Booklet that is available at the web site of the
Supply-Chain Council, www.supply-chain.org
Unless otherwise specified all information relates to SCOR 6.0.
7.13.2 SCOR summary
SCOR, the Supply-Chain Operations Reference-Model, integrates the three well-known concepts
of business-process re-engineering, cross-company benchmarking and process measurement into a
hierarchical model of supply chain processes. This model was specifically designed for effective
communication among supply-chain partners, and for this purpose it provides a standard language that
is used to describe, measure and evaluate supply-chain configurations. Using SCOR supply-chain
partners can:
•
describe supply-chain configurations, both internal and cross-company, using standard process
definitions
•
measure and benchmark using standard SCOR metrics, and
•
evaluate supply-chain configurations in support of improvement and strategic planning
SCOR is described by Paul Harmon from Business Process Trends as a second generation
methodology. Unlike previous methods which start from scratch to define processes and process
metrics, a second generation method provides a comprehensive framework complete with
hierarchically-structured pre-defined processes, corresponding metrics and associated best practices.
Benchmarking against other comparable companies is also an integral part of a second
generation method. According to the book Supply Chain Excellence by Peter Bolstorff, there are two
main sources of benchmark data. One source is The Performance Measurement Group (PMG), which
has a subscription contract with the Supply Chain Council to provide statistically significant supplychain data. A second source is public 10K financial data available from sources like hoovers.com.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 127 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
SCOR is intended for use in strategic and tactical planning of operations. Executable processes
are outside the scope of the model, but could be linked to SCOR level-3 processes.
The Supply-Chain Council (SSC)
The SSC, which develops SCOR, is a not-for-profit trade association with over 800 member
companies worldwide. Most of them are practitioners from all branches of industry and government
such as manufacturing, distribution, retail and the military.
History of SCOR
The council was organized in 1996 by Pittiglio Rabin Todd & McGrath (PRTM) and AMR
Research; it initially included 69 member companies. Work on SCOR is an on-going process, with new
versions of the model being released fairly regularly. Version 1.0 was released in 1997. Since then
versions 2, 3, 3.1, 4, 5 and 6 have been released, and version 7 will be released soon.
7.13.3 Overview of SCOR
SCOR is structured around five principal management processes: Plan, Source, Make, Deliver
and Return. These are organized into two process types and complemented by enable-type
processes. The SCOR Process types are:
•
Plan, which includes all processes related to planning the supply chain
•
Execution, which includes all processes directly related to the daily operation of the supply chain;
these are the Source, Make, Deliver, and Return processes
•
Enable, which are the processes that enable the two other types of process, that is, the Plan and
Execution type processes
SCOR is a hierarchical model. The following figure shows the levels of the hierarchy and
describes the purpose of each level.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 128 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
Level
Schematic
Plan
Source
Make Deliver
Return
Return
Customers
Suppliers
04.04.05
Description
1
Top Level
507849
Level 1 defines the
scope and content of
the model as well as
performance
attributes and
metrics.
Enable
Plan
2
P2
P1 Plan Supply Chain
P3
P4
P5
Source
S1
Configuration
Level
Make
M1
S2
M2
S3
M3
Level 3 Example:
3
S1 Source
Stocked
Process
Element Level
Inputs
Deliver
D1
D2
D3
D4
A supply chain can be
"configured-to-order"
at Level 2 from the
core process
categories which are
variants of the Level
1 processes.
Level 3 decomposes
Level 2 process
categories into
process elements and
their associated
inputs, outputs,
metrics and best
practices.
Process
Elements
Output
Not in scope
4
Level 4 is the
implementation level
and is outside the
scope of the model.
Implementation
Level
Figure 14.
SCOR Hierarchical Model
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 129 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
7.13.4 SCOR and collaboration
SCOR is designed for modeling both cross-company supply chains as well as internal supply
chains. Each link in the supply chain has its own source, make and deliver processes, unless it is just
a warehouse or transit center, in which case, it has no make processes. A link between two companies
is represented as a link from the supplier’s deliver process to the customer’s source process. Similarly,
if returns to the supplier are necessary, the supplier’s deliver-return process is linked to the customer’s
source-return process. Note that in the previous schematic, level 1, both types of return process are
named ‘return’; the return process underneath the source process is the source-return process, and
the one under the deliver process is the deliver-return process.
7.13.5 SCOR Level 1
Level 1 defines the five main management processes and the strategic metrics that define the
overall supply-chain performance. This is the level at which a supply chain sets it strategic goals and
relates them to the level-1 metrics.
7.13.6 SCOR Level 2
Process categories at level 2 correspond to different ways to do level-1 processes, for example
make-to-stock, is a way to make a product. All of the level-2 process categories for Source, Make and
Deliver are listed in the next diagram.
Figure 15.
Level 2 of SCOR
Level-2 processes are used to create thread diagrams, which are diagrams that show the
geographic locations in the supply chain, the level-2 processes at each location, and the links between
these processes. As can be seen from the example thread diagram below, the numbers of the
connected level-2 processes have to match, e.g., a D2 is connected to an S2. In a thread diagram a
solid line represents a boundary between two companies, whereas a dashed line represents a
company-internal boundary.
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 130 / 244
IP- Project
ATHENA -Project
Document
Figure 16.
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Example Thread Diagram
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 131 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
7.13.7 SCOR Level 3
Level 3 decomposes the level-2 process categories into sequences of process elements.
Elements have:
•
input/output associated with each process element
•
metrics to measure performance attributes of the element; Metrics have relations to process
elements and each other
•
best practices associated with the element
An example of a best practice is to use EDIFACT to exchange inventory data.
An example of a level-3 process is shown below.
Figure 17.
SCOR Level 3
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 132 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
7.13.8 List of SCOR Process Elements from SCOR 5.0 (Level 3)
The company Streamline SCM created a database model of SCOR, and as part of that work
created the following tables of SCOR process elements for SCOR 5.0. This list is included here to give
an idea of the scope and type of processes covered by SCOR at level 3.
Source
-
Make
Identify
Sources
Source
Negotiate
Schedule
Delivery
Receive
Product
Verify Product
Transfer
Product
Authorize
Payment
-
Finalize
Engineering
Schedule
Production
Issue Product
Produce &
Test
Release
Product
Deliver
-
Plan
Table 3.
-
Identify Excess
Inventory
Authorize
Return
Verify
Condition
Transfer
Return
Disposition &
Recover
Replace or
Credit
Enable
Identify
Requirements
Assess
Resources
Balance
Demand
Communicate
Plan
-
Process
Inquiry
Negotiate
Contract
Enter Order
Commit
Resources
Schedule
Installation
Consolidate
Orders
Plan & Build
Loads
Route
Shipments
Select Carrier
Pick Stage
Product
Ship Product
Receive
Warehouse
Install & Test
Invoice
Return
Rules
Performance
Information
Inventory
Assets
Transportation
Network
Config
Import/Export
Regulatory
Comply
Product
Lifecycle
Agreements
Process Elements (level 3)
-
7.13.9 SCOR Project
SCOR provides a framework for projects to improve supply chains. Such projects are organized
according to the SCOR levels as follows:
•
Level 1: Analyze the basis of competition and set the operations strategy
•
Level 2: Configure the supply-chain material flow and execution processes
•
Level 3: Align performance levels, practices and systems by aligning the information and work
flows
•
Level 4: Implement the supply-chain processes and systems (outside the scope of the model)
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 133 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
Metrics and benchmarking data are an integral part of a SCOR project. Benchmarking data is
used to decide if the company is at parity for its industry or not. Strategy has to do with setting the
goals for the level-1 metrics, that is, deciding if the company needs to achieve a parity, advantage or
superior position relative to the competition. One of the more difficult parts of a SCOR project is
calculating the actual values for SCOR metrics.
7.13.10 Metrics
Metrics are used at all levels of the SCOR model. At level 1, metrics measure the overall
performance of the supply chain in terms of the attributes: reliability, responsiveness, flexibility, costs
and assets. The next figure shows these performance attributes and the level-1 metrics to measure
them. The key to setting strategy is to determine which of these metrics is essential to success for the
particular supply chain, and to concentrate on improving the one or two that are essential.
Metrics and relationships between metrics are defined at all levels of SCOR. Of the 30 pages of
glossary in SCOR 6.0, 16 pages define metrics. The intent is to give precise definitions of metrics so
that everyone calculates them in the same way.
Figure 18.
Performance Attributes and Metrics
7.13.11 Tools
A number of tools support the SCOR model, e.g., StreamlineSCM, Aris EasySCOR and
www.scorwizard.com.
7.13.12 Relation to other vocabularies
Many of the best practices in SCOR recommend the use of existing standards like specific
EDIFACT transaction sets.
7.13.13 Potential significance of SCOR for Athena
SCOR can serve as a structure for organizing an Athena repository of collaborative business
processes for supply chains. In such a repository the SCOR hierarchy could be used as a taxonomy
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 134 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
for browsing and searching the repository. An example of a repository that already uses SCOR in this
way is The MIT Process Handbook. It includes a view of its collection of processes based on the
SCOR model.
SCOR has many places where CBPs might be linked to the model. For example, a lot of the best
practices in SCOR are related to collaboration. One example is the process Schedule Product
Deliveries which recommends as a best practice the use of EDI transactions like 830, 850, 856 & 862
to reduce cycle times. Other places where CBPs might be linked to the model are the links in the
thread diagrams, and process elements that have replenishment signals. No doubt a concerted effort
to use the SCOR model to organize a repository would uncover other places to link CPBs to SCOR.
A major advantage of linking CBPs to SCOR is that a SCOR project which provided the business
case for supply-chain improvements would automatically provide the business case for implementing
the associated CBP. A further advantage of using the SCOR model is that its rich structure would
enable more sophisticated searching, e.g., searching for processes to improve certain metrics, or
searching for processes that recommend the use of certain standards like EDIFACT.
The company Streamline SCM has already shown that SCOR can be put into a database. They
put the model into database form because they found that it had many errors which were easily
detected and fixed in the database version of the model. They also showed that the original word
document describing SCOR could be generated from the database version of the model. This is
another advantage that an Athena repository could provide, generation of various documents or other
artifacts from the repository data. And like the Streamline database, a repository can quickly and easily
perform consistency checks on modifications to the models. There are many implicit constraints in the
SCOR model that could be made explicit in a repository.
7.13.14 Other second-generation reference-models
SCOR has proven to be so successful that there are now efforts to extend the idea of reference
models to other business areas. In particular there is an on-going activity to define a reference model
for product-life-cycle management (PLM).
7.14 Conclusions
As seen from such standards as RosettaNet and ebXML, the basis of collaborative e-business is
messaging. Therefore, the basis of a business ontology should also be descriptions of messaging and
messages. Since there seems to be a convergence on ebXML Core Components, such an ontology,
or more appropriately, collection of modular ontologies, should reflect this fact, and be based on Core
Components.
Creating an ontology based on UBL, which is an implementation of Core Components, might be a
good start to creating a business ontology. UBL, like many other XML standards is derived from
EDIFACT, so that creating ontologies from various EDIFACT implementation guides is another
reasonable path.
One goal of creating an ontology based on Core Components should be the realization of a Core
Components repository. As described in the ebXML vision, the purposes of such a repository are:
•
To find components for re-use
•
To extend existing components for new needs
•
To harmonize extensions or additions which have been made by different organizations
Another goal of this messaging ontology should be to use it to improve the speed and quality of
data mapping. Currently this mapping process is done entirely by hand, and is time-consuming and
error-prone.
7.15 References
[1] The American Heritage Dictionary of the English Language. (2000), Houghton Mifflin, Boston
http://www.bartleby.com/61/ [Accessed 9 July 2004]
[2] Core Component Dictionary. 10 May 2001, Version 1.04. http://www.ebxml.org/specs/ccDICT.doc
[3] ebXML. ebXML Catalog of Common Business Processes v1.0. 11 May 2001
http://www.ebxml.org/specs/bpPROC.pdf [Accessed 9 July 2004]
[4] Fellbaum, Christiane et al. (1998) WordNet: an electronic lexical database. MIT Press
[5] Gefeg http://www.gefeg.com/en/edifix/files/EDIFIX5_Information.pdf
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 135 / 244
IP- Project
ATHENA -Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Programme
Deliverable A3.1 Part A
507849
04.04.05
[6] Gómez-Pérez, Asunción et al. (2004) Ontological engineering: with examples from the areas of
knowledge management, e-commerce and the semantic web. Springer-Verlag
[7] Malone, Thomas et al. (2003) Organizing Business Knowledge The MIT Process Handbook. The
MIT Press
[8] The MIT Process Handbook Project http://ccs.mit.edu/ph/
[9] Otto, Boris et al. (2002) E-Business Standards: Verbreitung und Akzeptanz. Fraunhofer-Institut für
Arbeitswritschaft und Organisation IAO
[10] UN/CEFACT. Core Components Technical Specification – Part 8 of the ebXML Framework. 15
November 2003, Version 2.01
[11] UN/CEFACT. Core Components User’s Guide. 13 March 2004 US Postal Service. Postal
Addressing
Standards,
Publication
28.
November
2000
http://pe.usps.gov/text/pub28/welcome.html
[12] Wright, Sue Ellen; Budin, Gerhard: Handbook of Terminology Management Volume 1. B.V.
Publishing, 1997.
[13] Bolstorff, Peter. Supply Chain Excellence: a handbook for dramatic improvement using the SCOR
model. AMACOM. 2003.
[14] Business Process Trends Whitepapers. http://www.bptrends.com/ “An Introduction to the Supply
Chain Council’s SCOR Methodology”, January 2003 “Second Generation Business Process
Methodologies”, May 2003
[15] PLM Group, spun-off from SCC, www.design-chain.org
[16] StreamlineSCM. paper on putting SCOR into a database:
http://www.streamlinescm.com/downloads.htm
050404_ATHENA_DA31_PartA_V10.doc
CONFIDENTIAL
Page 136 / 244
Programme
Integrating and Strengthening the European Research
Strategic Objective
Networked businesses and governments
Integrated Project / Programme Title
Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks
and their Application
Acronym
ATHENA
Project No
507849
ATHENA – Project Name
Knowledge Support and Semantic Mediation Solutions
ATHEN A - Project No
A3
DELIVERABLE D.A3.1
Title
SoA on Ontologies and the Ontology Authoring
and Management System, with Ontology
Modelling Language.
Part B: The Athos specifications
Leading Partner: CNR-IASI
Security Classification: Project Participants (PP)
March 16th, 2005
Version 1.0
IP- Project
ATHENA - Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
507849
A3
04.04.05
Versioning and contribution history
Version
0.1
Description
Structure of the document
Comments
0.2
Revised Structure
0.3
First draft
0.4
Updated version
1.0
Revised version based on feedback from peer reviewer Elmar Dorner (SAP).
Deliverable process schedule
No
1
2
3
4
5
Process step
Responsible
Initial drafting of the deliverable
including structure, comments and first F. Taglino (CNR)
basic content to be sent to to-beM.Missikoff (CNR)
contributors.
F.Taglino (CNR)
First round of contributions. Work
package member and others to
D. Gazzotti
contribute first iteration to owner of
(Formula)
the deliverable
S-M Thomas (SAP)
Owner to consolidate first round input
F. Taglino (CNR)
and distribute to contributors
F.Taglino (CNR)
L. Pondrelli
Final round of contributions including
(Formula)
comments form peers/AL to be sent to
S-M Thomas (SAP)
owner
E. Coscia (TXT)
F.W. Jaekel (IPK)
F. Taglino (CNR)
Final consolidation of input and
finalisation of “technical” document to
M. Missikoff (CNR)
be send to
G. Callegari (CNR)
Timing
05.07.2004
27.08.2004
22.10.2004
14.01.2005
28.01.2005
6
Quality check – e.g. Peer Review
Elmar Dorner (SAP)
14.03.2005
7
Final editing
26.07.2005
8
Final Approval from partners or
delegates to be send to Programme
Office
9
Submission to Commission
Programme office
PCC members or
delegates: Guy
Dougmeings (itrec)
Joerg Muller
(Siemens)
Programme Office
050404_ATHENA_DA31_PartB_V10.doc/derek
Comments
Only part B has been revised. We
didn’t receive any feedback for Part A
and B.
21.03.2005
31.03.2005
04.04.2005
CONFIDENTIAL
Page 137 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Table of Contents
1
Summary
141
1.1
The representational specifications of Athos
141
1.2
The functional and architectural specifications
141
1.3
Rationale of the document organization
141
2
Introduction
143
2.1
From Domain Generic to Domain Specific Ontology Languages
143
2.2
The rationale of OPAL
144
3
Related Work and Positioning of OPAL
145
4
Business Meta-Concepts in OPAL
147
4.1
Primary Concept Categories
147
4.2
Complementary Concept Categories
147
4.3
The OPAL templates
4.3.1
Identification Section
4.3.2
Structural Section
4.3.3
Object Specific Section
4.3.4
Process Specific Section
4.3.5
Actor Specific Section
4.3.6
Message Specific Section
4.3.7
Business Object Document Specific Section
4.3.8
Atomic Attribute Specific Section
4.3.9
Complex Attribute Specific Section
4.3.10
Operation Specific Section
149
149
149
151
151
151
152
152
153
153
154
5
155
Formalization of the OPAL Meta-Model
5.1
6
OPAL Abstract Syntax
155
Building a consistent ontology
159
6.1
OPAL Relations and inherent constraints
6.1.1
Generalisation (ISA)
6.1.2
Predication (Pr)
6.1.3
Decomposition (D)
6.1.4
Relatedness (R)
159
159
159
160
160
7
162
OPAL Semantics
7.1
The OPAL Semantics in OWL-DL
7.1.1
Identification Section
7.1.2
Structural Section
7.1.3
Specific Section
162
162
163
163
7.2
Axiomatization of OPAL
164
7.3
OPAL Ontologies in OWL-DL
168
8
Conclusions to the Athos Representational Specifications
173
9
The Athos functional and architectural specifications
174
9.1
Requirements and specifications
174
10 System Architecture
176
10.1
176
The Athos GUI
10.2 The Application tier
10.2.1
The Client Manager
10.2.2
The GUI Manager
050404_ATHENA_DA31_PartB_V10.doc/derek
177
177
177
CONFIDENTIAL
Page 138 / 244
IP- Project
ATHENA - Project
Document
10.2.3
10.2.4
10.3
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
The Application Logic Module
The Database Access Manager
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
178
179
The Database tier
179
11 The Athos plug-in model
180
11.1
The Eclipse plug-in model
180
11.2
The Protégé plug-in model
181
11.3 Athos plugin framework
11.3.1
ZExtension Point Description
182
183
11.4
183
The Athos Plug-in development
11.5 Plug-ins registration
11.5.1
Athos plug-in map
11.5.2
How to develop a new Athos plug-in
184
185
186
12 Athos web services
188
12.1
188
Introduction to web services
13 Zope: A Web Publishing Framework
190
13.1 Zope Components
13.1.1
ZPublisher
13.1.2
HTML document templates
13.1.3
Object database (ZODB)
190
190
190
190
13.2
190
Why Use Zope Instead of Another Application Server
14 Conclusions and Future Work
192
15 Appendix A
193
16 References
195
050404_ATHENA_DA31_PartB_V10.doc/derek
CONFIDENTIAL
Page 139 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Figures
Figure 1. ..... The three tiers knowledge framework............................................................................. 144
Figure 2. ..... The Order Processing example................................................................................... 148
Figure 3. ..... The Athos macro-architecture ........................................................................................ 176
Figure 4. ..... The Athos GUI ................................................................................................................ 177
Figure 5. ..... The Client Manager ........................................................................................................ 178
Figure 6. ..... The Application Logic...................................................................................................... 179
Figure 7. ..... The Eclipse plug-in relationships and roles .................................................................... 180
Figure 8. ..... Extension point ............................................................................................................... 181
Figure 9. ..... Callback object................................................................................................................ 181
Figure 10. ... The Athos plug-in Framework......................................................................................... 182
Figure 11. ... Plug-in registration – two ZExtension Points .................................................................. 185
Figure 12. ... Plug-in registration – two Extender plug-ins ................................................................... 185
Figure 13. ... The Athos plug-in map.................................................................................................... 186
050404_ATHENA_DA31_PartB_V10.doc/derek
CONFIDENTIAL
Page 140 / 244
IP- Project
ATHENA - Project
Document
1
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Summary
The part B is divided into two subparts. The first consists in the representational specifications of
Athos and the second in the architectural and implementation features.
1.1
The representational specifications of Athos
In building an Ontology Management Systems, such as Athos, the most relevant aspects is the
underlying ontology meta-model, that is the characteristics of the ontology modelling paradigm. Such a
paradigm determines the modelling capability of the system. In this respect, Athos is based on OPAL:
the Object, Process, Actor modeling Language. Today, one of the ontology languages that are gaining
a progressive consensus is OWL, the Ontology Web Language proposed by the W3C. On top of OWL,
the modelling method OPAL proposed a number of predefined concept categories that help the
ontology modeller in his/her task. The pre-defined categories of OPAL are associated with a number of
inherent integrity constraints. In fact, OPAL has been conceived having two main goals: to provide an
ontology building method capable of supporting and guiding the ontology modeller and to provide a
number of inherent constraints, associated to the above mentioned categories, used to guarantee a
better quality for the built ontology.
The concept categories of OPAL are organised in primary and complementary meta-concepts.
The primary meta-concepts are:
•
Object
•
Process
•
Actor
•
•
•
•
And complementary meta-concepts:
Attributes (atomic, complex)
Message
Business Document
Operation
There are additional meta-concepts, such as event and decision, that are not currently considered
for implementation. We will consider, after the first phase of experimentation, what to include in the
next release of Athso 2.0, due at month 20.
In the report, the formal specifications of OPAL 1.0 are provided, starting with an abstract syntax,,
represented with a concise algebraic method, and followed by its formal semantics, expressed using
OWL DL.
1.2
The functional and architectural specifications
The second subpart of this D.A3.1 Part B report presents the functional and architectural
specifications of Athos. In particular, the following modules are illustrated:
•
GUI Manager;
•
Client Manager;
•
Application Logic Module;
•
Database Access Manager.
Athos has been developed with two main architectural choices in mind:
Service Oriented Architecture: Athsos is fully WebService-enabled, on two fronts. In fact it is ready
to interact with external services, by using a SOAP interface, and at the same time it exhibits an
interface as a WebService, and it is ready to publish its semantic services over the Internet.
Plug-in Enabled. The second major issue concerns the possibility for Athos to evolve in a smooth
way, having structured its internal architecture according to the Plug-in philosophy. In particular, having
carefully studied the two plug-in models of Eclipse and Protégé, we defined conceived a particular
solution, based on the definition of ZExtension Points (where Z stands for Zope) that implements e
Plug-in approach by optimally usingise the characteristics of the Zope Platform, on which Athos is
based. The report contains a section of instructions on how to develop new Athos plug-ins.
1.3
Rationale of the document organization
The Part B of the Deliverable D.A3.1, describes the specifications of Athos, the Athena Ontology
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 141 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
management System.
•
•
There are two main aspects that are covered:
the representational specifications, essentially the description of OPAL, the ontology modelling
methodology that leads the ontology construction in Athos (from Section 2 to Section 8);
the technical specifications, that regard the architectural and implementation issues (from Section
9 to Section 14).
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 142 / 244
IP- Project
ATHENA - Project
Document
2
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Introduction
Domain ontology building is one of the most critical activities required in ontology-based
applications. The task is typically assigned to domain experts, who have in general neither the
background nor the experience of a knowledge engineer. To ease this task, ontology management
systems (such as Protégé[6], KAON[15], OntoEdit[7] or SymOntoX[5]) are characterized by user
friendly interfaces. However the problem is mainly of a cognitive nature and a GUI can only solve part
of it. The other part of the problem is represented by the inherent complexity of the conceptualization
activity and the ontology languages, difficult to be used by a domain expert, with a limited knowledge
engineering expertise.
Existing ontology languages (such as Ontolingua[14], SHOE[3], DAML+OIL[1], or OWL[2]) are of
a general purpose nature, giving therefore to the user great freedom but, conversely, low domain
specific guidance.
Enhancing domain specificity of ontology modeling languages will support domain experts in their
challenging task. Domain specificity can be achieved by means of two different approaches. One is to
provide a core domain ontology, containing the most general concepts that characterize a given
domain. Then domain experts can start building the ontology in a top-down fashion, by refining such
very general concepts (i.e., specializing the given super-concepts).
Another approach is to enrich the constructs of the ontology language with primitives that support
the user in ontology modeling. The two approaches are not mutually exclusive.
In this paper we will focus on the latter, illustrating a proposal for augmenting ontology languages
to be used in the business domain. In this perspective, we introduce the notion of “domain adequacy”
that, intuitively, represents for an ontology language the level of domain specificity.
2.1
From Domain Generic to Domain Specific Ontology Languages
Today ontology languages present two main drawbacks when used by business people: a syntax
which looks not “natural” and the absence of built-in primitives (i.e., modeling notions) they are familiar
with. For instance OWL, currently a standard language for ontology representation, has a strong
rooting in mathematical logic (in particular, DL: Description Logics) and is well suited to be processed
by inference engines. But, as anticipated, OWL is inherently domain generic, i.e., it is not conceived for
modeling one specific domain.
In this paper we present an ontology representation method that offers a number of modeling
notions useful in the e-Business domain, but general enough to be used in diverse business sectors
(such as automotive, tourism or banking). The proposed method includes an ontology language, built
on top of OWL, enriching its constructs to enhance domain specificity. To this end, we identify a
number of conceptual categories (referred to as concept kinds) aimed at supporting the construction of
ontologies in the business domain. Concept kinds support the domain expert in the conceptualization
process: the concepts identified observing the reality are categorized according to the given concept
kinds.
In essence, a concept kind represents a meta-concept, that becomes a new modelling notion of
the language. A meta-concept has a double nature:
•
it denotes all the domain concepts exhibiting similar features. For instance, all active entities (e.g.,
Business Actors) in a business domain can be grouped together, the same is true for passive
entities (see below);
•
it provides a rigorous structure for the templates used by domain experts in specifying a domain
concept. For instance, the meta-concept of Actor may require that when defining an Actor
concept, the actions it executes must be specified.
Instantiation, the operation performed in specifying a concept starting from a meta-concept, is
inherently equivalent to that performed when an individual is defined according to a given concept (the
former is referred to as meta-instantiation, the latter as ground instantiation).
Figure 1 depicts a three tier knowledge organization (along the line of RDFS(FA)[16]) where metaconcepts are located on the top layer, super-concepts are on the middle layer and ground instances
are on the lower layer.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 143 / 244
IP- Project
ATHENA - Project
Document
Figure 1.
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
The three tiers knowledge framework
The first concept categories proposed for the business domain are: Business Object, Business
Process, Business Actor, Business Event, Business Message, Business Goal (for sake of
conciseness, we will drop the term “business” in the rest of the document). Taking the first three
conceptual categories, we refer to our approach as OPAL (Object, Process, Actor modelling
Language).
The indicated categories have been selected after an analysis of the most relevant business
modeling languages, such as Rosettanet[9], OAGIS[12], ebXML[11], BPML[10], and UML[13].
Particular attention has been paid to the latter that, even if originally conceived for software
development, is progressively gaining popularity in business and enterprise modelling.
2.2
The rationale of OPAL
The main objective of OPAL is to provide an ontology representation method that incorporates
(categorial) elements of the target domain, to support and guide business experts when building and
maintaining an ontology. In this direction, such method should:
•
provide guidelines for domain experts in analyzing the problem domain and organizing its
conceptualization;
•
reduce cost and time required for domain ontology building;
•
enhance the quality of the built ontology, with a support for consistency checking that involves
domain specific constraints.
Domain specificity is not aimed at improving the expressive power; conversely, a language that
exhibits a higher specificity in a given domain is less usable in a different domain. Domain specificity
reduces the generality (i.e., applicability) of an ontology language, but allows more synthetic, concise,
precise sentences to be formulated in the specific domain (intuitively, we may say that the same
content can be represented by a reduced number of sentences, i.e., a shorter string).
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 144 / 244
IP- Project
ATHENA - Project
Document
3
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Related Work and Positioning of OPAL
In starting our work, as anticipated, we considered a number of Business Modeling proposals. In
particular we refer to two among the most relevant proposals in the area of ontology and conceptual
modeling: UML and OWL.
UML is considered today the most popular diagrammatic notation for conceptual modeling[8].
Initially proposed by Rational Software, and then by OMG for information systems analysis and design,
over the time, thanks to its very rich set of modeling constructs, it has been progressively adopted by
the business community. Business processes, organization charts, business documents and resources
are represented in UML for purposes not directly connected to software development. Business
Process Reengineering, enterprise modeling and analysis, managerial decision support documents
are among the business resources modeled by using UML.
UML owes its success to a number of positive features, sketchily summarized in the following
points.
•
A widely accepted standard at industrial level;
•
Increasing popularity in business and enterprise modeling;
•
Intuitive and easy to use, especially when a relevant subset is considered (e.g., Use Case, Class
Diagram, Activity Diagram);
•
Very good for communicating among people;
•
Powerful notation for expressing constraints (OCL [8]) ;
•
Object-oriented modeling approach (e.g., class is a central notion, attributes exist within a class) ;
•
A scope which is constantly expanding (see UML 2.0), and a foreseeable bright future (e.g., see
OMG-MDA Fehler! Verweisquelle konnte nicht gefunden werden.).
•
•
•
•
•
•
•
However, there are a number of shortcomings, sketchily summarized in the following points:
very complicated if its full power is used (e.g., low popularity of OCL);
redundancy in modeling diagrams and constructs, with a very large total number of modeling
notions (almost 300);
mixed semantics: mainly procedural (except Use Case and Class Diagram) and intuitive (except
OCL);
no methodological support in managing a full, enterprise-wide repository of diagrams (scales
poorly);
no support in maintaining the coherence between different diagrams referring to the same
problem area, or even the same entities;
poor for communicating among machines (despite the emerging of its linear form: XMI);
no query method, no consistency maintenance (due to the lack of formal semantics in the
standard), no reasoning tools (a part a few partial attempts).
On the other side, OWL (Ontology Web Language) is a recent proposal of W3C for ontology
modeling that is quickly gaining great attention from the scientific community. OWL is the evolution of
previous proposals: DAML and OIL (with their synthesis DAML+OIL). The main characteristic of OWL
is its rooting in Description Logics[17], with a sound mathematical basis and a number of advanced
tools for reasoning over ontologies. Here a few important positive characteristics of OWL are
summarized:
•
a sound proposal coming from W3C that is gaining a wide consensus, not only in academia;
•
the emerging Semantic Web considers OWL as a central element;
•
few but comprehensive modeling notions (a dozen of primitive language constructors);
•
different levels of the language (OWL-Lite, -DL, -Full), with increasing expressiveness;
•
declarative specification, formal Model Theoretic semantics (full axiomatization);
•
efficient reasoning tools, provided by a large and active scientific community;
•
good computational characteristics (thanks to the “controlled” expressive power) ;
•
very good for communication among machines;
•
general purpose: potentially any domain can be modeled;
•
logic-oriented modeling approach (modeling based on predicates, unary and binary; attributes are
first-class citizens).
Conversely, it is not foreseeable that OWL will challenge the wide usage of UML, mainly due to
the vision that originated OWL, which is inherently different from UML. With respect to its adoption for
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 145 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
e-Business, there are a few limitations sketchily reported below:
•
among the different syntaxes proposed, none is particularly suited for communication between
(business) people;
•
no domain specific constructs suited to support the modeling of a business domain (it is a
“general purpose” language);
•
reduced expressive power (e.g., no behavioral modeling);
•
limited modularity, with respect to the management of large ontologies (owl:import construct);
•
the logics-based approach is not intuitive for business people (e.g., the fact that attributes, e.g.,
binary predicates, can be defined independently of entities.).
With OPAL we intended to get from UML and OWL the features that are best suited to model an
e-Business application ontology: an intuitive, easy to use modeling method, while keeping a sound and
rigorous formal basis. In particular we intend to keep the possibility of building complex enterprise
models starting from a few basic categories (e.g., Object, Process, Actor, taken from UML) and
allowing a domain expert to model the business ontology according to them. At the same time, we
wanted to use the advanced reasoning and query services typical of DL and OWL. In summary, with
OPAL we intend to propose an ontology representation method able to leverage on the positive
features of the two, minimizing the negative aspects.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 146 / 244
IP- Project
ATHENA - Project
Document
4
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Business Meta-Concepts1 in OPAL
In this section, we introduce a first set of concept categories (meta-concepts) useful in modeling a
business domain that are at the basis of the proposed ontology representation method. In OPAL we
distinguish between primary concept categories (that have their initials included in the acronym) and
complementary concept categories, used to refine the former.
4.1
Primary Concept Categories
The primary concept categories are at the basis of the proposed method and provide the
backbone of an OPAL ontology.
Business Object
A Business Object (O)2 is a category that gathers passive entities involved in one or more
business processes (subject to the so called CRUD lifecycle: create, read, update, delete). It is seen
as an information object, representative of a material or an immaterial entity in the real world..
Process
A business Process (P) is a category that gathers business activities. A Process aims at
accomplishing one or more business goals, operating on a set of Business Objects (e.g. PurchaseOrder-Issuing, Request-for-Quotation-Sending). It can be rather simple, with a limited duration in time,
or complex, with parallel branches and phases that last for a long time span.
Actor
A business Actor (Ar) is an active element of a business domain (e.g. Buyer, Supplier). The
domain expert, in analyzing the reality, is asked to identify relevant actors that operate producing,
updating or consuming business objects. An Actor can be an enterprise, a computer system, an
employee, or a business unit.
Actors, as Objects and Processes, can be organized according to specialization and
decomposition hierarchies, in order to obtain a more structured view of the business domain.
Processes can be recursively decomposed into Processes and, finally, into Operations (Op), the latter
being not further decomposable.
4.2
Complementary Concept Categories
In OPAL we identified other conceptual categories typical of the e-Business domain, such as,
Message, Business Object Document, Business State, Goal, Event, Rule (restrictive or prescriptive)
and Decision. These categories have been identified having considered several languages and
methodologies. For instance, the OPAL Goal is drawn from i*[18], Messages are defined along the line
of FIPA3 and the speech act theory Fehler! Verweisquelle konnte nicht gefunden werden..
We believe that these additional concept categories will contribute in enhancing the domain
adequacy of our proposal, however, their formal account within the OPAL methodology is currently at a
preliminary stage, thus we are not going to further elaborate all of them here.
Business Object Document (BOD), represents a type of document in the business domain (e.g.,
Invoice, RFQ)
Message (M), represents the interaction (e.g., exchanging of info, request, response) between
processes. It is characterized by a content that is a BOD (e.g., RFQ-Message, that carries a RFQ)
Operation, represents an activity that is not further decomposable. Its use depends on the level of
details we are managing (e.g., Insert Supplier info).
Complex Attribute and Atomic Attribute, in modeling the properties of a concept, we distinguish
1
We experimented already a preliminary version of the proposed method in two EU Projects: Fetish
and Harmonise, where an interoperability platform, based on a tourism ontology, has been built. The
proposed approach has been further elaborated within IDEAS and is currently at the base of the
ontology research in the 6FP European Projects: INTEROP Noe and the Athena IP.
2
We will refer to Business Object also as Object.
3
www.fipa.org
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 147 / 244
IP- Project
ATHENA - Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
507849
A3
04.04.05
between structured information, such as “address”, and elementary information, such as “street name”.
Essentially, a (structured) Complex Attribute (CA) is defined as an aggregation of lower level CA
and/or Atomic Attributes (AA).
Besides the concept categories, the OPAL model includes semantic relations defined among
categories. The OPAL semantic relations represent well known modeling notions common to (the
meta-model of) the majority of Knowledge Representation Languages:
ISA (generalization) relation among concepts. E.g., an Invoice is an Accounting Document;
Predication: relating attributes to a concept. E.g., an invoice is in predication relation with date,
amount, recipient, …;
Decomposition: part-of relationship among concepts. E.g., a department is a part of an enterprise;
Relatedness: domain specific relationships (named or unnamed) among concepts. E.g., the
invoice is related to the customer (unnamed), the customer buys the product (named).
The above relations will be further elaborated in the sequel, when OPAL templates will be used.
To concretely illustrate how the OPAL method is used in building a business ontology, we
introduce an example drawn from an e-Procurement process, focusing on the Order Processing
phase.
This example represents a typical process that takes place between a Supplier and a Buyer
exchanging the documents necessary to accomplish a purchasing. The following steps are considered:
•
a Buyer sends a Request for Quotation (RFQ) to a Supplier;
•
the Supplier processes the RFQ and sends his/her Quotation to the Buyer;
•
the Buyer evaluates the Quotation and (possibly) prepares the Purchase Order (PO);
•
the Buyer issues the Purchase Order to the Supplier;
•
the Supplier (possibly) accepts the Purchase Order;
•
the Supplier fulfills the Purchase Order;
•
the Supplier delivers the Goods, accompanied by a Delivery Notification, and then sends the
Invoice to the Buyer;
•
the Buyer verifies the Goods and pays the Invoice.
In this process we identified two actors, the Buyer and the Supplier, some business documents
that can be modeled as Objects, such as the Request for Quotation (RFQ), the Purchase Order (PO),
the Invoice, and some sub-processes, such as the sending and processing of the RFQ, or the
Purchase Order issuing.
Figure 2 illustrates the Purchase Order processes: on the left column the process on the Buyer
side is represented, while on the right column the Supplier process is reported. In the middle, the
exchanged documents are indicated.
Buyer Process
Order Processing
Sending RFQ
RFQ
Evaluating
Quotation
Quot.
Issuing PO
Processing RFQ
Processing PO
Purchase
Order
Fulfilling PO
Receiving Goods
Del Not
Delivering Goods
Paying Invoice
Invoice
Invoicing
BUYER
Figure 2.
Supplier Process
SUPPLIER
The Order Processing example
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 148 / 244
IP- Project
ATHENA - Project
Document
4.3
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
The OPAL templates
In OPAL, a concept is specified according to a traditional Frame-Slot-Facet modeling paradigm[4].
In particular, there is a frame structure (template) for each concept category (kind, in OPAL templates),
such templates are used in the interface of Athos to allow the user to introduce domain concepts in the
ontology.
All the templates are characterized by three sections:
1) Identification Section, that essentially contains traditional metadata, such as the concept label,
description, and other information (such as creation date, author) with an administrative flavour;
2) Structural Section, that contains the slots corresponding to the attributes (simple or complex) that
will be instantiated in the corresponding object; it contains also the semantic relations (such as
ISA, decomposition, etc.) with other concepts;
3) Specific Section, that contains information and references to other entities that play a specific role
(predefined) in the correct definition of the concept.
The first two sections are the same for all the three templates, while the third section is designed
specifically for each template, with the aim to represent domain specific links and dependencies.
Below we briefly describe the first two common sections; furthermore, we present the specific
sections for each template.
4.3.1
Identification Section
The Identification Section allows descriptive information about the concept to be specified. It
contains
•
Label: the preferred term to refer the concept;
•
Identifier : the unique identifier for the concept;
•
Kind: the concept category the concept belongs to;
•
XMLtag: a tag that can be used to refer the concept in an XML document;
•
Description: a natural language description of the concept;
•
References: documental source used for the definition of the concept;
•
Terminology: a set of terms that can be considered synonyms of the preferred term used as label
•
Author: the person that entered the concept specification in the ontology;
•
Defined/Updated: the date when the concept was first defined, and then updated.
•
Below, a sketchy representation of an Identification Section of Purchase Order is reported.
Label: PurchaseOrder
Identifier: PO
Kind: O
XMLTag: <po>
Description: A printed or typed document, issued by the Buyer Purchasing FU as a firm and formal
request to a specific Manufacturer/Supplier to produce and supply goods/services according to
Price, Terms and Conditions previously agreed and approved
Terminology: Order, Product Order, Service Order
Author: Federica
4.3.2
References:Merriam_Webster
Defined_Updated: 02-04-04
Structural Section
A Structural Section is built by using a set of modeling notions derived from the OWL constructors,
plus the PartOf relation (Decomposition).
Attributes and semantic relations have been introduced earlier, here a few additional issues are
reported.
•
Concept constructors: allow the new concepts to be defined, by using logical operators:
•
Intersection (∩), Union (∪), Negation (¬): it is possible to introduce a concept by defining it as the
intersection (union/complement) of already existing concepts;
•
Concept Axioms: formulas asserting specific constraints on concepts. These axioms, introduced
in the Structural Section of the concept template, represent global constraints, valid every time we
refer to the concept. The constraints that can be specified are:
o Disjontness,
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 149 / 244
IP- Project
ATHENA - Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
507849
A3
04.04.05
o Equivalence;
Property Axioms: formulas asserting specific constraints or describing particular characteristics of
the properties. These axioms, introduced in the Structural Section of the template, represent local
constraints, valid only if the properties are applied to an instance of the considered template. The
constraints that can be specified are:
o Cardinality constraints: allow to specify the cardinality of attributes and relations concerning the
concept;
o Explicit constraints: axioms expressed by using the OCL language. (Please note that in this
phase, OCL constraints are not yet deployed.);
o Property characteristics: Functional, InverseFunctional, Symmetric, Transitive;
•
Relatedness additional features: as introduced in the previous section, the Relatedness relation
allows to model domain specific relationships; these relationships can be named or unnamed. In
case of named Relatedness, a property Rel_name can be valued with the label of the relation.
Furthermore the Inv_rel_name can be specified as the inverse name of the relation.
•
Please, note that in the ATHOS system, the concept constructors are not yet implemented. They
require a further elaboration, in particular for what concerns the inference mechanisms that allow to
derive the inherited properties and detect possible inconsistencies among concept definitions.
Having OWL as a formal rooting of OPAL, we had to cope with a number of misalignments caused
by the different nature of the two modeling methods: logic-oriented and frame-oriented, respectively.
For instance, in OPAL we assume that the definition of a relation in the Structural Section is local
with respect to the concept. In the OWL perspective, a relation defined in this section of the template
corresponds to a property. We must guarantee that the domain of this property is a superset of the
considered concept; furthermore, in the definition of this concept, a Restriction on the range of the
property must be added. In the next sections we will see how these constraints are expressed.
Continuing the Purchase Order example, in the Structural Section we have:
Label: PurchaseOrder
ISA: Accounting Document
Decomposition: BusinessDocumentArchive
Predication: PONumber, OrderLine, OrderDate, Charge, PaymentTerms, TransportTerms,
DeliveryDate
Relatedness: DeliveryNote, Invoice, Payment, Product, Shipping List
ConceptConstuctors
None
Concept Axioms
None
Property Axioms:
PONumber: type=integer;
cardinality=1;
InverseFunctional
PaymentTerms: type=string;
Values={cash, cheque,
credit card};
cardinality=1;
OrderLine:
cardinality>=1;
OrderDate:
type=string;
cardinality=1;
TransportTerms: type=string;
Values={by rail, by
road, by sea};
cardinality=1;
DeliveryDate:
type=string;
cardinality=1;
Relatedness additional features
DeliveryNote:
Invoice:
Invoice:
cardinality=0..1;
cardinality=0..1;
Rel_name=’originate’;
Inv_rel_name=’is_originated_by’
Further details concerning Attributes, Relations and Hierarchies will be given in the next sections.
An OPAL template is completed by the Specific Section, which is different for each concept
category. The Specific Section gathers a number of domain-oriented axioms, aimed at capturing
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 150 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
additional semantics.
4.3.3
•
•
•
•
Object Specific Section
An Object has a Specific Section that reports the following information:
GeneratedBy, UpdatedBy, UsedBy, ArchivedBy: the Processes that create, manipulate, archive
the Object;
ObjOwner: the Actors that have the responsibility of the whole lifecycle of the object;
States, labelled boolean expressions over the Object attributes or those of related concepts;
Invariants: specific constraints that must be always satisfied by the Object instances.
The last two items are currently treated informally. Their formal representation need further
analysis of OCL.
The Object Specific Section, instantiated for the Purchase Order example, is:
Label: PurchaseOrder
GeneratedBy: IssuingPO
UpdatedBy: RequestingOrderStatus
UsedBy: ProcessingPurchaseOrder
ArchivedBy: ClosingPO
ObjOwner: BuyerPurchasingFU
States, {Issued, Confirmed, Open, Modified, Hold, Blocked, Cancelled, Fulfilled, Paid, Archived}
Invariants: the PO date follows the corresponding Quotation date and preceeds the Invoice date.
4.3.4
•
•
•
•
Process Specific Section
The relations that are part of the Specific Section of the Process template are:
Creates, Updates, Enquires and Archives Business Objects: the business objects that are directly
accessed or manipulated by the Process;
In, Out and Fault Messages: the incoming, outgoing messages of the Process. The Fault
messages: allow to model the exceptions handling;
Actors: the actors that are requested for the execution of the Process;
EstimatedTime: the estimation of the Process execution time.
Label: ProcessingRFQ
Business Objects
Creates: Quotation-Doc
Updates:
Enquires: RequestForQuotation-Doc
Archives:
Messages
In: RFQ-Msg
Out: Quotation-Msg
Fault: Warning-Msg
Actors: SupplierCommercialFU{performer, enabler}
EstimatedTime: 3 days
4.3.5
•
•
Actor Specific Section
The relations that are specified in the Specific Section of the Actor are:
Goals: objectives that must be accomplished by the Actor, in the form of an OCL expression (e.g.,
salaries should be less that 60% of department budget);
Skills: indicating the actions it is able to perform or monitor (i.e., list of processes and/or
operations);
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 151 / 244
IP- Project
ATHENA - Project
Document
•
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Responsibilities: the processes in which the Actor is involved, in achieving a Goal (as above),
with his/her/its respective role (i.e., performer, controller, stakeholder, supporter), and the Objects
he/she/it can manage;
Collaborations: the other actors involved in the performed activities.
•
Label: PurchasingFunctionalUnit
Goals: BetterPerformanceGoodsPurchasing
Skills: IssuingRFQ, EvaluatingRFQ, Issuing PO
Responsabilities:
(SendingRFQ,{Enabler, Performer}, {Request For Quotation-Doc}),
(IssuingPO ,{Enabler,Performer}), {Quotation-Doc, PurchaseOrder-Doc})
Cooperation: BAdministrativeFU, BGenericFU, BReceivingFU
4.3.6
Message Specific Section
A Message (M) is here considered as a particular case of Business Object. Assuming that, the
Message templates is a specialization of the Object template. It means that all the features of the
Object template are in the Message template, and at the same time in the Message template we have
some more characteristics.
•
•
•
•
•
•
The relations that are part of the Specific Section of the Message template are:
Source, the Actors who can send the message;
Destination, the Actors who can receive the message;
Content, the Business Object Document that is carried by the Message;
PrecedingMessages, the set of Messages that can precede a given Message in the iteraction
between two Processes;
FollowingMessages, the set of Messages that can precede a given Message;
PreCondition, a boolean expression that must be true in order to allow the sending of the
Message.
Label: Quotation-Msg
Source: SupplierCommercialFU
Destination: BuyerPurchasingFU
Content: Quotation-Doc
PrecedingMessages: RFQ-Msg
FollowingMessages: PurchaseOrder-Msg
Precondition:
4.3.7
Business Object Document Specific Section
Like the Message template, also the Business Object Document (BOD) template is here
considered as a particular case of Business Object and then considered as a specialization of the
Object template.
•
•
The relations that are specifically part of the Specific Section of the BOD template are:
AuthoredBy, the Actors who can be identified as the authors of the BOD;
CarriedBy, the Messages that can carry the BOD as their actual content;
Label: RFQ-Doc
GeneratedBy: SendingRFQ
UpdatedBy:
UsedBy:ProcessingRFQ
ArchivedBy: ProcessingRFQ
AuthoredBy: BuyerPurchasingFU
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 152 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
CarriedBy:RFQ-Msg
State: {Issued, Modified, Blocked, Cancelled, Archived}
4.3.8
•
•
•
•
Atomic Attribute Specific Section
The features of the Specific Section of the Atomic Attribute template are:
Domain, the set of concepts for which a predication with the Attribute can be established. Please,
note that, if this property is valued with a list of concepts, the domain must be interpreted as the
union of the set of instances of the specified concepts;
Range, the basic type of the attribute. It assumes its values in the following set of values: string,
integer, real and boolean;
Functional, boolean value that says if for each instance of the Domain there is at most one
instance of the Attribute (if more than one, then they represent the same object);
InverseFunctional boolean value that says if for each instance of the Range there is at most one
instance of the Domain.
Please, note that in the Specific Section of the Atomic Attribute the range of the Attribute can be
specified. This assertion is a global constraint: it means that the concept indicated as range must be
considered as the larger set in which the attribute can assume its values.
In the Structural Section of a concept ci it is also possible to specify the type of the Attribute when
it is related via a Predication (or Decomposition) to ci. In this case, that specification must be
considered as a further restriction imposed over the range of the Attribute; this restriction is local to the
definition of ci.
As well as the Range, also the Property Characteristics (e.g. Functional) can be specified in the
Specific Section of the Attribute. In this case, every time the Attribute is related to a concept, the
constraint must be satisfied. Otherwise, the constraint can be specified in the Structural Section of a
given ci; in this case the constraint will be local to the definition of the ci Predication (or
Decomposition).
All the costraints specified in the Specific Section must be considered as global, while the
constraints specified in the Structural Section are local.
Label: ItemId
Domain: {}
Range:String
Functional: true
InverseFunctional: true
4.3.9
•
•
•
Complex Attribute Specific Section
The features of the Specific Section of the Complex Attribute template are:
Domain, the set of concepts for which a predication with the Attribute can be established;
Functional, boolean value that says if for each instance of the Domain there is at most one
instance of the Attribute (if more than one they represent the same);
InverseFunctional boolean value that says if for each instance of the Range there is at most one
instance of the Domain.
Label: OrderLine
Domain: {PurchaseOrder, Invoice}
Functional: true
InverseFunctional: false
As well as the Atomic Attribute, the constraints specified in the Specific Section of the Complex
Attribute must be interpreted as global constraints over the Attribute.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 153 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
4.3.10 Operation Specific Section
The Specific Section of Operation is exactly the same of the Process. What differentiates the
Operation from the Process is the fact that the former is not further decomposable.
In the remaining part of the paper we will present a first formalization of the OPAL Ontology metamodel. This formalization includes the abstract syntax of the OPAL templates and the formal
semantics. The abstract syntax is addressed in the next section. The specification of the formal
semantics is expressed by using an axiomatic approach, i.e., the OPAL constructs will be mapped to
OWL-DL. It will be given in Section 7.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 154 / 244
IP- Project
ATHENA - Project
Document
5
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Formalization of the OPAL Meta-Model
In this section we illustrate, with an algebraic approach, the formal structures that compose the
definition of a concept. It can be seen as the abstract syntax of the representation language.
5.1
OPAL Abstract Syntax
Let O be an OPAL ontology , O = (C, R)
C = {ci, i ∈ N} is a finite set of concepts
R = {(ci, ck) i, k ∈ N} is a finite set of relations established among concepts in C.
•
•
•
•
•
In particular we have
ISA the set of Generalization relations defined in O ;
D the set of Decomposition relations defined O;
Pr the set of Predication relations defined in O ;
R the set of Relatedness relations defined in O;
Furthermore, R includes also the set of relations in the Specific Section of each template (Sp).
R = ISA ∪ D ∪ Pr ∪ R ∪ Sp
A concept ci ∈ C, is defined as a triple
ci = (IdentSecti, StructSecti, SpecSecti)
where each element is a set of functions:
IdentSecti= [label(ci), id(ci), kind(ci), XMLtag(ci), descr(ci), ref(ci), terminology(ci), author(ci),
def(ci)]
•
label(ci) ∈ String; the label of the concept (the label is mandatory);
•
id(ci) ∈ String; the unique identifier of the concept;
•
kind(ci) ∈ {Ar,O,P,AA,CA,Op,M, BOD}; the concept category the concept belongs to (the kind is
mandatory. The pair (label(ci), kind(ci)) must be unique);
•
XMLTag(ci) ∈ String; an XML tag that can be used to refer the concept in an XML document;
•
descr(ci) ∈ String; a natural language description of the concept;
•
ref(ci) ∈ String; sources for the concept definition;
•
terminology(ci) ∈ String; a set of terms that are considered synonyms of the concept;
•
author(ci) ∈ String; the name of the author;
•
def(ci) ∈ Date; the date of the concept definition.
In the Purchase Order (PO) example, we will have:
IdentSect (PO) = [Purchase Order, “PO”,“O”,“<po>”,“A printed or typed document, issued by the
Buyer Purchasing FU as a firm and formal request to a specific Manufacturer/Supplier to produce and
supply goods/services according to Price, Terms and Conditions previously agreed and approved.”,
“ebXML”, {Order, Product Order, Service Order}, Federica, 02-04-04].
•
•
•
•
•
•
•
•
StructSecti= [ISA(ci), Pr(ci), D(ci), R(ci), intersectionOf(ci), unionOf(ci), not(ci)]
ISA(ci) = {ck | (ci,ck) ∈ ISA , k ∈ {1,…,n}}; it gathers the set of superconcepts of ci;
Pr(ci) = {ck | (ci,ck) ∈ Pr , k ∈ {1,…,n}}; it gathers the set of ci attributes;
D(ci) = {ck | (ci,ck) ∈ D , k ∈ {1,…,n}}; it gathers the components of ci;
R(ci) = {ck | (ci,ck) ∈ R , k ∈ {1,…,n}}; it gathers the set of concepts related to ci;
intersectionOf (ci) = { c1 ,.., ck }; it indicates that the concept ci is defined as the intersection of the
concepts c1, .. , ck;
unionOf (ci) = { c1 ,.., ck }; it indicates that the concept ci is defined as the union of the concepts c1,
.. , ck;
not (ci) = { ck , k ∈ {1,…,n}}; it indicates that the concept ci is defined as the complement of the
concept ck.
For the Purchase Order, in the Structural Section we will have:
ISA(PO) = {AccountingDocument};
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 155 / 244
IP- Project
ATHENA - Project
Document
•
•
•
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Pr(PO)={PONumber, OrderLine, OrderDate, Charge, PaymentTerms, TransportTerms,
DeliveryDate};
D(PO) = {BusinessDocumentArchive};
R(PO) = {DeliveryNote, Invoice, Payment, Product, Shipping List}.
These relations will be further detailed in the next section.
For what concerns the disjointness and equivalence Concept Axioms, they are represented by
functions
•
disjoint: P(C) Æ {‘true’, ‘false’}, where P(C) is the power set of C ;
•
equivalent: P(C) Æ {‘true’, ‘false’}, where P(C) is the power set of C
The assertion disjoint( c1 ,.., ck) means that { c1 ,.., ck } is a set of pair wise disjoint concepts.
The assertion equivalent( c1 ,.., ck) means that { c1 ,.., ck } is a set of pair wise equivalent concepts.
For what concerns Property Axioms, Cardinality constraints and Property characteristics are
referred to the semantic relations and therefore are expressed as binary functions that take in input a
pair of concepts.
When a Predication (or Decomposition) relation is established between two OPAL concepts, the
type of the attribute can be specified, by using the functions type and dataRange. These functions can
be applied to a pair of concepts related by either the Predication or the Decomposition relation,
depending on the kind of the second element of the pair.
If the Decomposition relation is established between a Complex Attribute and an Atomic Attribute,
the type of the attribute must be specified by using the type and, possibly, the dataRange functions.
•
type: D ∪ Pr Æ {’string’, ‘int’, ’real’, ’boolean’}.
NOTE: type is a partial function; type((ci,ck))=undefined if kind(ck) ≠ AA
In the Purchase Order example:
type(PurchaseOrder,PONumber)=‘int’
•
Please note that this approach implies the locality of typing. In fact, the same attribute label may
be bound, for another concept, to a different type. This is one of the main differences between the
frame-oriented approach of UML, adopted in OPAL, and the logical approach of OWL.
dataRange: D ∪ Pr Æ INTERVAL ∪ ENUM
The latter function specifies a restriction on the values the attribute can assume. We indicate with
INTERVAL a subset of INT × INT or REAL × REAL. We also indicate with ENUM a finite set of
STRINGS or INT.
dataRange can assume the following values:
o dataRange((ci,ck)) = (x,y) ∈ INT × INT if type((ci,ck)) = ‘int’;
o dataRange((ci,ck)) = (x,y) ∈ REAL × REAL if type((ci,ck)) = ‘real’;
o dataRange((ci,ck)) = x ∈ ENUM if type((ci,ck)) = ‘string’;
Being dataRange a partial function, it is undefined if kind(ck) ≠ AA.
In the Purchase Order example:
type(PO,PaymentTerms)=‘string’
dataRange(PO,PaymentTerms)={cash, credit card, bank transfer} ∈ ENUM.
Furthermore, cardinality constraints can be specified for an attribute or a relation, by using the
following functions:
•
minCard(ci,ck) ∈ INT
•
NOTE: optional; if not specified, 0 is assumed.
maxCard(ci,ck) ∈ INT
NOTE: optional; if not specified, it is unbounded.
•
Other Property Axioms can be expressed by using the following functions:
Functional: R ∪ Pr ∪ D Æ {‘true’,’false’,‘not-spec’};
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 156 / 244
IP- Project
ATHENA - Project
Document
•
•
•
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
507849
A3
04.04.05
InverseFunctional: R ∪ Pr ∪ D Æ {‘true’,’false’,‘not-spec’};
Symmetric: R ∪ Pr ∪ D Æ {‘true’,’false’,‘not-spec’};
Transitive: R ∪ Pr ∪ D Æ {‘true’,’false’,‘not-spec’}.
Finally, when a Relatedness relation is established, the label of the relation can be specified by
using the Rel_name and the Inv_rel_name functions.
•
Rel_name: R Æ STRING
•
Inv_rel_name: R Æ STRING
In the Purchase Order example:
Rel_name(PurchaseOrder, Invoice)=‘originate’
Inv_rel_name(PurchaseOrder, Invoice)=‘is_originate_by’
•
ActorSpecSecti = [Goals(ai), Skills(ai), Responsabilities(ai), Cooperations(ai)]
Goals(ai) = {(l, d), l ∈ String, d ∈ String};
Skills(ai) = {p | (ai, p), p ∈ P};
Responsabilities(ai) = {(p, r, o) | (ai, p, r, o), ai ∈ Ar , p ∈ P, r ∈ {“performer”, “controller”,
“stakeholder”, “supporter”}, o ∈ O };
Cooperations(ai) = {ak | (ai, ak) ak, ai ∈ Ar, ak ∈ Ar}.
•
•
•
•
•
ObjectSpecSecti = [GeneratedBy(oi), UpdatedBy(oi), UsedBy(oi), ArchivedBy(oi), States (oi)]
GeneratedBy(oi) = { p | (oi, p), oi ∈ Ο, p ∈ P};
UpdatedBy(oi) = { p | (oi, p), oi ∈ Ο, p ∈ P};
UsedBy(oi) = { p | (oi, p), oi ∈ Ο, p ∈ P};
ArchivedBy(oi) = { p | (oi, p), oi ∈ Ο, p ∈ P};
States(oi) = {(l, d), l ∈ String, d ∈ String}.
•
•
•
ProcessSpecSecti = [Creates(pi), Updates(pi), Enquires(pi), Archives(pi), InMessages(pi),
OutMessages(pi), FaultMessages(pi), Actors(pi), EstimatedTime(pi)]
•
Creates(pi) = {o | (pi, o), o ∈ O};
•
Updates(pi) = {o | (pi, o), o ∈ O};
•
Enquires(pi) = {o | (pi, o), o ∈ O};
•
Archives(pi) = {o | (pi, o), o ∈ O};
•
InMessages(pi) = {m | (pi, m), m ∈ M};
•
OutMessages(pi) = {m | (pi, m), m ∈ M};
•
FaultMessages(pi) = {m | (pi, m), m ∈ M};
•
Actors(pi) = {a | (pi a), a ∈ Ar};
•
EstimatedTime(pi) = t | (pi, t), t is a non negative number.
MessageSpecSecti = [Source(mi), Destination(mi),
FollowingMessages(mi)]
•
Source(mi) = {a | (mi, a), a ∈ Ar};
•
Destination(mi) = {a | (mi, a), a ∈ Ar};
•
Content(mi) = d | (mi, d), a ∈ BOD;
•
PrecedingMessages(mi)= {m | (mi, m), m ∈ M};
•
FollowingMessages(mi)= {m | (mi, m), m ∈ M};
•
•
Content(mi),
BusinessObjectDocumentSpecSecti = [AuthoredBy(bi), CarriedBy(bi)]
AuthoredBy(bi) = {a | (bi, a), a ∈ Ar};
CarriedBy(bi) = {m | (bi, m), m ∈ M};
AtomicAttributeSpecSecti
=
[Domain(ti),
Range(ti),
InverseFunctional(ti)]
•
Domain(ti) = {c | (ti, c), c ∈ Ar ∪ O ∪ P∪ M∪ BOD};
•
Range(ti) = r ∈ {“String”, “Integer”, “Float”, “Boolean” };
•
Functional(ti) = f ∈ {“true”, “false”});
•
InverseFunctional(ci) = i ∈ {“true”, “false”}
•
PrecedingMessages(mi),
EquivalentTo(ti),
Functional(ti),
ComplexAttributeSpecSecti = [Domain(ci), EquivalentTo(ci), Functional(ci), InverseFunctional(ci)]
Domain(ci) = {c | (ci, c), c ∈ Ar ∪ O ∪ P∪ M∪ BOD};
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 157 / 244
IP- Project
ATHENA - Project
Document
•
•
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Functional(ci) = f ∈ {“true”, “false”};
InverseFunctional(ci) = i ∈ {“true”, “false”};
OperationSpecSecti = [Creates(pi), Updates(pi), Enquires(pi), Archives(pi), InMessages(pi),
OutMessages(pi), FaultMessages(pi), Actors(pi), EstimatedTime(pi)]
•
Creates(pi) = {o | (pi, o), o ∈ O};
•
Updates(pi) = {o | (pi, o), o ∈ O};
•
Enquires(pi) = {o | (pi, o), o ∈ O};
•
Archives(pi) = {o | (pi, o), o ∈ O};
•
InMessages(pi) = {m | (pi, m), m ∈ M};
•
OutMessages(pi) = {m | (pi, m), m ∈ M};
•
FaultMessages(pi) = {m | (pi, m), m ∈ M};
•
Actors(pi) = {a | (pi a), a ∈ Ar};
•
EstimatedTime(pi) = t | (pi, t), t is a non negative number.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 158 / 244
IP- Project
ATHENA - Project
Document
6
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Building a consistent ontology
As anticipated in the Section 1, the introduction of concept categories, besides representing
guidelines for the ontology developer, has the purpose of improving the quality of an ontology. This is
achieved by introducing a number of axioms and providing automatic consistency checking.
Consistency is valuable if a sufficient number of axioms (i.e., semantic constraints) is introduced in the
ontology. We distinguish three sorts of constraints:
Inherent constraints – imposed by the modeling method, they need not to be explicitly expressed
by the modeler. E.g., the acyclicity of a ISA hierarchy.
Built-in constraints – specific language constructs, having a precise semantics. E.g., disjoint(A,B)
asserts that the concepts A and B do not have common instances.
Explicit constraints – defined by the user by means of a constraint language (such as OCL). The
semantics of an explicit constraint is computed by the system on the basis of the supplied
constraint expression.
In OPAL a rich set of constraints inherent to the ontology representation model are provided,
reducing the amount of code (and therefore, of effort, time, and errors) that an ontology engineer has
to write when building a domain ontology. To this end, the introduction of concept kinds is particularly
effective. For instance, in both specialization and decomposition hierarchies the concepts must have
the same kind.
In the next section we present a first set of inherent constraints of the OPAL model. Such
constraints are assumed when an OPAL ontology is constructed and automatically enforced by Athos.
6.1
OPAL Relations and inherent constraints
In the following, the OPAL relations are formally described and, for each of them, the inherent
constraints of the OPAL model are presented. The examples illustrating the constraints are taken from
the business domain.
6.1.1
Generalisation (ISA)
Generalisation (inverse: Specialisation) expresses the relation between a narrower and a broader
concept. In our example the concept AccountingDocument is specialized into PurchaseOrder.
The first constraint is that ISA relation must be defined among concepts belonging to the same
conceptual category (e.g Objects, Actors, Processes); accordingly, AccountingDocument and
PurchaseOrder are both Objects.
Formally, let ci (i=1,…,n) be concepts, let kind(ci) be the OPAL category of the concept ci, the
following constraint must be verified:
C1)
(ci,ch) ∈ ISA ⇒ kind(ci) = kind(ch)
Furthermore the Specialisation relation is transitive and must be acyclic.
C2)
(ci,ch), (ch,ck) ∈ ISA ⇒ (ci,ck) ∈ ISA (transitivity)
C3)
there are no sequences c1..cn such that (c1,c2), …(cn-1,cn) ∈ ISA and c1=cn (acyclicity)
6.1.2
Predication (Pr)
Predication expresses the relation among a concept and its attributes. For example the
PurchaseOrder concept can have as attributes the concepts PONumber and OrderLine.
Since this relation typically connects a primary concept with Complex Attributes (the OrderLine, in
our example, since it is an aggregate of day, month and year) or Atomic Attributes (the PONumber), it
must be defined between concepts whose kinds are defined as follows:
C4)
(ci,ch) ∈ Pr ⇒ kind(ci) = O | Ar | P | M | BOD , kind(ch) = CA | AA)
When a Predication relation is established between two OPAL concepts, the cardinality
constraints can be specified by using the minCard and maxCard functions previously introduced.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 159 / 244
IP- Project
ATHENA - Project
Document
6.1.3
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Decomposition (D)
Decomposition expresses the relation between a composite concept and a concept representing
one of its components. For example an Enterprise can be decomposed into Departments or an
Address can be decomposed into City, Street, Number and ZipCode.
The involved concepts must satisfy one of the following constraints, depending on their kinds:
C5)
(ci,ch) ∈ D and kind(cj) = Ar | O | M | BOD ⇒ kind(cj) = kind(ci)
C6)
(ci,ch) ∈ D and kind(cj) = CA ⇒ kind(ch) = AA | CA
C7)
(ci,ch) ∈ D and kind(cj) = P ⇒ kind(ch) = P | Op
When a Decomposition relation is established between two OPAL concepts, the cardinality
constraints can be specified by using the minCard and maxCard functions previously introduced.
6.1.4
Relatedness (R)
Relatedness expresses the fact that, between two concepts, a domain relation exists. Such
domain relation can be labeled. For example an Enterprise can be related to a Manager with a relation
named manages.
Furthermore, since the related concepts may be of different kinds one of the following conditions
holds:
C8)
(ci,ch) ∈ R and kind(ci) = Ar | O | P | M | BOD ⇒ kind(ch) = Ar| O | P | M | BOD
C9)
(ci,ch) ∈ R and kind(ci) = CA | AA | Op ⇒ kind(ci) = kind(cj)
When a Relatedness relation is established between two OPAL concepts, the cardinality
constraints can be specified by using the minCard and maxCard functions previously introduced. A
name can be specified for the relationship, as well as the name of the inverse relations. It can be done
by using the functions
relName(ci,ck) ∈ STRING
invRelName (ci,ck) ∈ STRING
Each reations in the Specific Section of an OPAL template must satisfy the following domain
constraints:
C10)
Let S be a relation in the Object Specific Sections,
C11)
(ci,ch) ∈ S ⇒ kind(ci) = O
Let S be a relation in the Process Specific Sections,
C12)
(ci,ch) ∈ S ⇒ kind(ci) = P
Let S be a relation in the Actor Specific Sections,
C13)
(ci,ch) ∈ S ⇒ kind(ci) = A
Let S be a relation in the Message Specific Sections,
C14)
(ci,ch) ∈ S ⇒ kind(ci) = M
Let S be a relation in the Business Object Document Specific Sections,
C15)
(ci,ch) ∈ S ⇒ kind(ci) = BOD
Let S be a relation in the Complex Attribute Specific Sections,
C16)
(ci,ch) ∈ S ⇒ kind(ci) = CA
Let S be a relation in the Atomic Attribute Specific Sections,
C17)
(ci,ch) ∈ S ⇒ kind(ci) = AA
Let S be a relation in the Operation Specific Sections,
(ci,ch) ∈ S ⇒ kind(ci) = Op
Also the range of the relations in the Specific Sections is constrained.
C18)
(ci,ch) ∈ GeneratedBy ⇒ kind(ch) = P
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 160 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Similarly, the ranges of the other specific relations can be desumed by the description of the
Specific Section given in the abstract syntax description.
In the Specific Section of some templates have properties that relate an object to a tuple. For
instance, in the Actor Specific Section the Responsabilities relation is definied as follow:
Responsabilities(ai) = {(p, r, o) | (ai, p, r, o), ai ∈ Ar , p ∈ P, r ∈ {“performer”, “controller”,
“stakeholder”, “supporter”}, o ∈ O };
The range of this relation is constrained to assume values in the set of tuples [Process, role,
Object]. This set is given by the cartesian product of the sets in which processes, roles and objects can
assume values.
C19)
(ai, p, r, o) ∈ Responsabilities ⇒ (p, r, o) ∈ P × Roles × O ,
where Roles = {“performer”, “controller”, “stakeholder”, “supporter”}
Similarly, the range of the other specific relations can be desumed by the description of the
Specific Section given in the abstract syntax description.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 161 / 244
IP- Project
ATHENA - Project
Document
7
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
OPAL Semantics
In this section we present the OPAL semantics by using an axiomatic approach (i.e., Axiomatic
Semantics as opposed to Model Theoretic Semantics [13]). To this end, we will specify the OPAL
constructs in OWL. This approach, besides expressing the semantics of OPAL, shows how an OPAL
ontology is represented in OWL.
In order to express the OPAL model in OWL, we need to enrich the OWL set of modeling notions:
we must define a set of OWL classes and properties that represent the OPAL concept categories and
relations, respectively. It is also necessary to translate the OPAL constraints in OWL axioms.
Since OWL is articulated in three expressiveness levels: Lite, DL, and Full, we need to identify the
suitable level to be considered. Since we need to express the OPAL kinds, i.e., meta-concepts, OWLDL is not sufficiently expressive. In fact, it is too limitative in the restrictions it imposes, such as the
type separation: a class can not be an instance (only ground instantiation is allowed). This means that
an OWL-DL Class cannot represent, for instance, the OPAL Object kind, since we need to instantiate it
to define a domain concept (e.g., the PurchaseOrder Class). Conversely, the expressive power of
OWL-Full allows multiple instantiation levels to be defined.
Furthermore, in OWL the resources ObjectProperty and DatatypeProperty are disjoint. In OPAL,
the Predication relation relates Actors, Objects and Processes to either Complex Attributes (that are
represented as OWL classes) or Atomic Attributes (that corresponds to datatypes). This means that
some instances of the Predication should be represented as ObjectProperties, others as
DatatypeProperties.
Since meta-classes cannot be expressed in OWL-DL, we have two options: consider the use of
OWL-Full or the possibility of collapsing the two upper levels of OPAL (i.e., meta and concept level) in
the single class level of OWL-DL. The drawback is that using OWL-Full decidability is compromised. If
we adopt OWL-DL we shift the modeling paradigm of OPAL from meta-classes to super-classes. It
means that we will not provide the ontology modeler with new constructs for the OWL-DL language,
but we will provide a number of superclasses (i.e., Object, Process, Actor will be superclasses of a
stem ontology) to which the user-defined concepts will be related with an ISA link.
In practice, there will be an OWL (Top) Class for each OPAL concept category and an OWL (Top)
Property for each OPAL relation. In building an OPAL Ontology, each concept ci will be a subclass of
the class that represents the OPAL kind the concept ci belongs to. Each relation (ci,ck) in the ontology
will be a subproperty of the Property that represents the OPAL relation.
7.1
The OPAL Semantics in OWL-DL
In order to use OWL-DL to represent the modeling notions of OPAL, we introduce the stem
superclasses and superproperties, corresponding to the OPAL kinds and relations, below.
Please note that, for sake of conciseness, OWL is represented with N3 syntax, instead of the
more traditional XML one.
Classes that represent concept kinds
Object Æ <OBJECT> a owl:Class;
Process Æ <PROCESS> a owl:Class;
Actor Æ <ACTOR> a owl:Class;
Message Æ <MESSAGE> a owl:Class;
BusinessObjectDocument Æ <BOD> a owl:Class;
ComplexAttribute Æ <COMPLEX_ATTRIBUTE> a owl:Class;
AtomicAttribute Æ represented as Datatype Property
Operation Æ <OPERATION> a owl:Class;
7.1.1
Identification Section
Below we show some elements of the Identification Section, represented by means of OWL
constructs.
rdfs:label
Concept label Æ
Concept description Æ rdfs:comment
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 162 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
507849
A3
04.04.05
<XMLtag> a owl:DatatypeProperty;
rdfs:domain [
a owl:Class;
owl:unionOf (<ACTOR> <OBJECT> …)];
rdfs:range xsd:String.
XMLtag Æ
7.1.2
IP- Project - No
ATHENA - Project Number
Date
Structural Section
In the Structural Section we have essentially the attributes, listed under the Predication relation,
and the relationships: Decomposition, Relatedness, ISA. The latter is natively represented in OWL, the
others are represented by means of ObjectProperties.
Rdfs:subClassOf
<PREDICATION> a owl:ObjectProperty;
<DECOMPOSITION> a owl:ObjectProperty;
<RELATEDNESS> a owl:ObjectProperty;
ISA Æ
Predication Æ
Decomposition Æ
Relatedness Æ
NOTE: domains and ranges of these properties will be properly defined in the next section, in
order to express the OPAL constraints.
For what concerns Concept constructors and Axioms that the modeler can specify in the
Structural Section, they have a correspondence with some OWL modeling notions. The following table
illustrates the translation.
Concept
constructors
Intersection (∩) Æ owl:intersectionOf
Union (∪) Æ owl:unionOf
Negation (¬) Æ owl:complementOf
Enumeration Æ owl:one of
Concept Axioms Disjointness:
disjont Æ owl:disjointWith
Equivalence:
equivalent Æ owl:equivalentTo
Property Axioms Cardinality constraints:
MaxCard Æ owl:maxCardinality
MinCard Æ owl:minCardinality
Property Characteristics
FunctionalÆ owl:FunctionalProperty
InverseFunctionalÆ owl: InverseFunctionalProperty
Symmetric Æ owl:SymmetricProperty
TransitiveÆ owl:TransitiveProperty
Finally, if the Structural Section contains the definition of a named Relatedness, the name of this
Relatedness is translated as the label of the OWL property that will represent that Relatedness.
Relatedness
additional features
7.1.3
Rel_name Æ rdfs:id
Inv_rel_name Æ rdfs:id
Specific Section
In the Specific Section of Objects, Processes, Actors, Messages and Business Object Documents,
the properties are represented by means of ObjectProperties. The name of the property is the label of
the specific relation. In the following table, only the properties representing the Specific Section of the
Actor template are listed. The other Specific Sections representations for the listed concept categories
are straightforward.
Actor Specific Section
GoalsÆ
Skills Æ
Responsabilities Æ
<GOALS> a owl:ObjectProperty;
<SKILLS> a owl:ObjectProperty;
<RESPONSABILITIES> a owl:ObjectProperty;
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 163 / 244
IP- Project
ATHENA - Project
Document
Cooperations (
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
<COOPERATIONS> a owl:ObjectProperty;
NOTE: domains and ranges of these properties will be properly defined in the next section.
The properties in the Specific Section of Complex Attributes, Atomic Attributes allow to specify
some axioms such as the domain and range of an attribute, etc. They can be translated by means of
existing OWL modeling notions. In the following tables, the respective representations are listed.
Domain(
Range (
Functional (
InverseFunctional (
7.2
rdfs:domain
rdfs:range
owl:FunctionalProperty;
owl:InverseFunctionalProperty;
Axiomatization of OPAL
In this part we address a first proposal of OPAL axiomatization in OWL-DL. Essentially, since the
OPAL (inherent) constraints will be expressed by using the OWL primitives, it is necessary to verify to
what extent OWL allows them to be expressed and, if positive, find the most suitable way to express
such constraints. If negative, i.e., there is no possibility to express a constraint in OWL, we will specify
it in formal terms and then, from the operational point of view, we will implement a procedural
attachment to the selected Theorem Prover capable of verifying the satisfiability of such constraint.
C1: Concepts in ISA must have the same kind
Using the subClassOf property to represent the inverse of the ISA, and defining the concept
categories (super-classes) as disjoint.
<ACTOR> a owl:Class;
owl:disjointWith <OBJECT>;
owl:disjointWith <PROCESS>;
…
The same stands for the Object class.
C2: The ISA relation is transitive
OWL subclassOf is a transitive property.
C3: The ISA relation is acyclic
OWL subclassOf is not required to be acyclic. In addition, there is no way to express such a
constraint by means OWL primitive. In this case we provide a procedural method to verify it.
C4: Objects, Actors and Processes can be in Predication only with Complex or
Atomic Attributes
This means that in OPAL, the Predication relation can be applied only to Ar, O, P, M, BOD or P;
then we define the domain of the Predication Property as the union of the ACTOR, OBJECT,
PROCESS, MESSAGE, BOD and PROCESS Classes (rdfs:domain.)
As anticipated, the Predication Property defined in OWL to represent the OPAL Predication
relation is an owl:ObjectProperty and represents only the Predication between a primary concept and a
ComplexAttribute. In this case, to express the constraint we define the range of this property as the
ComplexAttribute Class (rdfs:range).
Atomic Attributes are considered Datatypes and the Predication with AA is translated into a
DatatypeProperty, so the constraint C4 can be represented only for CA.
The OWL property representing the OPAL predication relation is defined as follows
<PREDICATION> a owl:ObjectProperty;
rdfs:domain [
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 164 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
a owl:Class;
owl:unionOf (<ACTOR> <OBJECT> <PROCESS> <MESSAGE> <BOD>)];
rdfs:range < COMPLEX_ATTRIBUTE>.
In order to clarify the translation of the Predication relations, we anticipate an example of a
Predication involving a Complex Attribute and one involving an Atomic Attribute. In the PO example,
(PurchaseOrder, OrderLine) ∈ Pr and kind(OrderLine) = CA. The following ObjectProperty is
generated:
<has_OrderLine> a owl:ObjectProperty;
…
rdfs:domain [
a owl:Class;
owl:unionOf (<Invoice_Object> <PurchaseOrder_Object>)];
rdfs:range <OrderLine_ComplexAttribute>;
rdfs:subPropertyOf <PREDICATION>.
As an example of a Predication relation involving an Atomic Attribute, in the same example, a
Predication relation involving an Atomic Attribute is the following: (PurchaseOrder, PONumber) ∈ Pr
and kind(PONumber) = AA. After creating the DatatypeProperty labeled “has_PONumber”
<has_PONumber> a owl:DatatypeProperty;
rdfs:domain [
a owl:Class;
owl:unionOf (<Invoice_Object> <PurchaseOrder_Object> …)].
The following Restriction is added in the definition of the class “PurchaseOrder_Object”:
<PurchaseOrder_Object> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <has_PONumber>;
allValuesFrom xsd:integer].
Please, note that the type function (valued as ‘int’ in the PO template) is used to determine the
XML built-in datatype to be used to restrict the range of the Datatype Property.
C5: imposes restrictions over the domain and the range of the Decomposition relation applied to Actors and
Objects.
Domain constraints are expressed by the built-in constraint rdfs:domain.
Range depends on the value of the domain. So these constraints are embedded in the definition
of the ACTOR, and the OBJECT, MESSAGE and BOD classes, using an owl:Restriction in the
definition of the classes representing the concept categories.
The Decomposition domain is as follows:
<DECOMPOSITION> a owl:ObjectProperty;
rdfs:domain [
a owl:Class;
owl:unionOf (<ACTOR> <OBJECT> <PROCESS> <MESSAGE> <BOD> <COMPLEX_ATTRIBUTE>].
The Decomposition relation, when applied to the Actor class is constrained to assume values in
the Actor class:
<ACTOR> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <DECOMPOSITION>;
allValuesFrom <ACTOR>].
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 165 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Similarly for the Object, Message and BOD classes.
C6: imposes restrictions over the domain and the range of the Decomposition relation applied to
ComplexAttributes and AtomicAttributes.
For the Range constraints, since we decided to translate AtomicAttributes as Datatype Properties,
this constraint will affect only the definition of the COMPLEX_ATTRIBUTE class and it will be
expressed using an owl:Restriction.
<COMPLEX_ATTRIBUTE> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <DECOMPOSITION>;
allValuesFrom [
a owl:Class;
owl:unionOf (<COMPLEX_ATTRIBUTE> <ATOMIC_ATTRIBUTE>)]
].
C7: imposes restrictions over the domain and the range of the Decomposition relation applied to Processes and
Operations.
Range depends on the value of the domain. So these constraints are embedded in the definition
of the PROCESS class using an owl:Restriction.
<PROCESS> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <DECOMPOSITION>;
allValuesFrom [
a owl:Class;
owl:unionOf (<PROCESS> <OPERATION>)
]].
C8: restrictions over the domain and the range of the Relatedness relation, for the
A, O, P, M, BOD, CA, AA, Op.
Domain constraints are expressed by the built-in constraint rdfs:domain.
Range depends on the value of the domain. So these constraints are embedded in the definition
of the classes using an owl:Restriction.
<RELATEDNESS> a owl:ObjectProperty;
rdfs:domain [
a owl:Class;
owl:unionOf (<ACTOR> <OBJECT> <PROCESS> <MESSAGE> <BOD> <COMPLEX_ATTRIBUTE>
<OPERATION>)].
When applied to Actors, the Relatedness can assume values in concepts belonging to the Actor,
Object, Process, Message and BOD categories. Then, in the ACTOR Class definition we add a
Restriction on the Relatedness property.
<ACTOR> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <RELATEDNESS>;
allValuesFrom [
a owl:Class;
owl:unionOf (<ACTOR> <OBJECT> <PROCESS> <MESSAGE> <BOD>)
]].
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 166 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
The same kind of restriction will be added in the definition of the OBJECT, PROCESS, MESSAGE and
BOD and OPERATION classes.
C9: restrictions over the domain and the range of the Relatedness relation, for CA, and AA and Op.
Range depends on the value of the domain. So these constraints are embedded in the definition
of the COMPLEX ATTRIBUTE and OPERATION classes using an owl:Restriction.
<COMPLEX_ATTRIBUTE> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <RELATEDNESS>;
allValuesFrom <COMPLEX_ATTRIBUTE>].
<OPERATION> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <RELATEDNESS>;
allValuesFrom <OPERATION>].
For what concerns the Atomic Attributes the Relatedness cannot be expressed.
C10-C18: restrictions over the domain and range of relations in the Specific
Sections.
The domain of the relations belonging to the Object Specific Section, must be the class OBJECT
and the range must be the class PROCESS. For instance, the definition of the GENERATED_BY
property is:
<GENERATED_BY> a owl:ObjectProperty;
rdfs:domain <OBJECT>;
rdfs:range <PROCESS>.
Similarly, all the constraints in the Specific Sections can be translated.
C19: (ai, p, r, o) ∈ Responsabilities ⇒ (p, r, o) ∈ P × Roles × O ,
where Roles = {“performer”, “controller”, “stakeholder”, “supporter”}
For what concerns the relations involving a tuple of objects, domain and range must be properly
specified. These relations actually represent an n-ary relation; for instance, the Responsabilities
relation in the Actor Specific Section represents the relation among an actor, a process, a role and an
object. In the OPAL templates it has been reduced to a binary relation between an actor and a tuple
[process, role, object].
In translating this relation in OWL, we still treat it as a binary relation.
The domain of this relation will be the class representing the Actor concept category; the range
will be an OWL class with three properties: process, role and object, valued respectively in the
PROCESS, ROLE and OBJECT classes. The PROCESS and OBJECT classes are the owl classes
representing the Process and Object concept categories; the ROLE class is the class defined as
<ROLE> a owl:Class;
owl:equivalentClass [
a owl:Class;
owl:oneOf (“performer”, “controller”, “stakeholder”,
“supporter”);
].
The class representing the range of Responsabilities will be a class having three attributes valued
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 167 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
with the elements of the tuple. The attributes are represented by the following Object Properties
<Proc> a owl:ObjectProperty;
rdfs:domain <RESPONSIBILITIES_RANGE>;
rdfs:range <PROCESS>.
<Role> a owl:ObjectProperty;
rdfs:domain <RESPONSIBILITIES_RANGE>;
rdfs:range <ROLES>.
<Obj> a owl:ObjectProperty;
rdfs:domain <RESPONSIBILITIES_RANGE>;
rdfs:range <OBJECT>.
The RESPONSABILITIES_RANGE class is defined as
<RESPONSABILITIES_RANGE> a owl:Class;
Concluding, the Responsabilities relation is translated as follows:
<Responsabilities> a owl:ObjectProperty;
rdfs:domain <ACTOR>;
rdfs:range <RESPONSABILITIES_RANGE>
].
7.3
OPAL Ontologies in OWL-DL
In this part we show how, based on the axiomatization given in the previous section, we can
express an OPAL ontology in OWL-DL.
1)
2)
3)
4)
Steps of the transformation:
Let O be the OPAL ontology
Build a namespace for the ontology O
Import the file containing the definition of the OPAL model
Create the OWL classes and properties representing the concepts and the relations in O.
The translation criteria concerning the last step are expressed in the following.
The Purchase Order running example will be used to show the output of the transformation
process.
Translation criteria: concepts
For each concept c ∈ C , an OWL class is created, such that kind(c) ∈{Ar, O, P, M, BOD, CA, Op}.
This class is asserted to be a subclass of the class representing the respective kind the concept
belongs to.
In the PO example, the concept PurchaseOrder is an Object. To translate in OWL this concept,
the following definition is generated:
<PurchaseOrder_Object> a owl:Class;
…
rdfs:subClassOf [
a opal:OBJECT;
].
The label of the class is obtained from the concatenation of the label of the concept and the name
of the concept category it belongs to. In OPAL, two concepts with the same label and different kind can
exist in the same ontology, while, in OWL, the resource identifier must be unique. So the
concatenation of the pair give us the unique ID to be assigned to the class representing an OPAL
concept.
Furthermore, the values of the metadata properties of the concept are asserted. These properties
are the Datatype Properties representing the metadata in the Identification Section of the OPAL
template.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 168 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
In the PO class definition, the following assertions are added:
<PurchaseOrder_Object> a owl:Class;
…
rdfs:label “PurchaseOrder“;
opal:identifier “PO“;
opal:XMLtag “po“;
opal:label “PurchaseOrder“;
opal:comment “A printed or typed document, issued by the Buyer Purchasing FU as a
firm and formal request to a specific Manufacturer/Supplier to
produce and supply goods/services according to Price, Terms and
Conditions previously agreed and approved“;
opal:terminology “Order, Product Order, Service Order“;
opal:author “Federica“;
opal:references “Merriam Webster“;
opal:defined_updated “02/04/04“;
…
.
If kind(c) = AA, then we define a new DatatypeProperty; the label will depend on the relation in
which the AA is with other concepts. For example, the PONumber is an AtomicAttribute. The following
property is generated:
<has_PONumber> a owl:DatatypeProperty;
<owl:DatatypeProperty rdf:ID="has_PONumber"/>
See the following section, describing the translation of the Predication and Decomposition
relations, for further details.
Translation criteria: relations
For each relation (ci,ck) ∈ R an OWL property is created. Depending on the relation type (ISA,
Predication, Decomposition, Relatedness, or one of the relations in the templates specific secitons), a
set of OWL assertions is generated, concerning the new properties.
ISA Relations
For each (ci,ck) ∈ ISA, ci is asserted to be a subclass of ck.
In the PO example, we add the following assertion in the definition of the PurchaseOrder_Object
class:
<PurchaseOrder_Object> a owl:Class;
…
rdfs:subClassOf <AccountingDocument_Object>
…
Predication Relations
For each (ci,ck) ∈ Pr, if kind(ck) = CA, an ObjectProperty is generated, labelled with the
concatenation of the string “has_” and the label of the CA ck. The range of the property is the OWL
class representing ck. The domain is the union of all classes representing the concepts that are related
via a Predication to ck. Furthermore, the property is asserted to be subPropertyOf the PREDICATION
property.
In the PO example, (PurchaseOrder, OrderLine) ∈ Pr and kind(OrderLine) = CA. The following
ObjectProperty is generated:
<has_OrderLine> a owl:ObjectProperty;
rdfs:range <OrderLine_ComplexAttribute>
rdfs:domain [
a owl:Class;
owl:unionOf (… <PurchaseOrder_Object> …)];
rdfs:subPropertyOf <opal:PREDICATION>.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 169 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
For each (ci,ck) ∈ Pr, if kind(ck) = AA, the class representing ci, is added to the domain of the
DatatypeProperty representing the AA ck. In fact, the domain of this property is the union of all classes
representing the concepts that are related via a Predication to ck. Furthermore a Restriction in the
definition of the class representing the ci concept is asserted. The restriction constrains the
DatatypeProperty representing the AA to assume its values in the XML built-in datatype corresponding
to the type of the Predication.
In the PO example, (PurchaseOrder, PONumber) ∈ Pr and kind(PONumber) = AA.
The AA is repesented with the following Datatype Property:
<has_PONumber> a owl:DatatypeProperty;
rdfs:domain [
a owl:Class;
owl:unionOf (<Invoice_Object> <PurchaseOrder_Object>)].
The following Restriction is added in the definition of the class “PurchaseOrder_Object”:
<PurchaseOrder_Object> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <has_PONumber>;
allValuesFrom <xsd:integer>].
Decomposition Relations
Similarly to the Predication, for each (ci,ck) ∈ D, if kind(ck) ≠ AA, an ObjectProperty is generated,
labelled with the concatenation of the string “hasPart_” and the label of the concept ck. The range of
the property is the OWL class representing ck. The domain is the union of all classes representing the
concepts that are related via a Decomposition to ck. Furthermore, the property is asserted to be
subPropertyOf the DECOMPOSITION property.
In the PO example, (BusinessDocumentArchive, PurchaseOrder) ∈ D. The following
ObjectProperty is generated:
<hasPart_PurchaseOrder_Object> a owl:ObjectProperty;
rdfs:range <PurchaseOrder_Object>
rdfs:domain [
a owl:Class;
owl:unionOf (… <BusinessDocArchive_Object> …)];
rdfs:subPropertyOf <opal:DECOMPOSITION>.
For each (ci,ck) ∈ D, if kind(ck) = AA, , the class representing ci, is added to the domain of the
DatatypeProperty representing the AA ck. In fact, the domain of this property is the union of all classes
representing the concepts that are related via a Decomposition to ck. Furthermore a Restriction in the
definition of the class representing the ci concept is asserted. The restriction constrains the
DatatypeProperty representing the AA to assume its values in the XML built-in datatype corresponding
to the typing of the Decomposition.
In the PO example, OrderLine is decomposed into the following Atomic Attributes: ItemId,
ItemDescription, Quantity and Price.
(OrderLine, ItemId) ∈ D and kind(ItemId) = AA.
The AA is repesented with the following Datatype Property:
<hasPart_ItemId> a owl:DatatypeProperty;
rdfs:domain [
a owl:Class;
owl:unionOf (… <OrderLine_Object>)…].
The following Restriction is added in the definition of the class “OrderLine_ComplexAttribute”:
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 170 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
<OrderLine_ComplexAttribute> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <hasPart_ItemId>;
allValuesFrom <xsd:string>].
Relatedness Relations
For each (ci,ck) ∈ R an ObjectProperty is generated. The label of this property depends on the
kind of relatedness: if it is an unnamed Relatedness, the label of the property is the concatenation of
the string “relTo_” and the label of the concept ck. If the Relatedness is named, the label of the
property is the concatenation of the relation name and the label of the concept ck.
The range of the property is the OWL class representing ck. The domain is the union of all classes
representing the concepts that are related via a Relatedness to ck. Furthermore, the property is
asserted to be subPropertyOf the RELATEDNESS property. Finally, if the Relatedness is unnamed,
the property is asserted as symmetric.
In the PO example, (PurchaseOrder, Invoice) ∈ R. The following ObjectProperty is generated:
<originate_Invoice_Object> a owl:ObjectProperty;
rdfs:range <Invoice_Object>
rdfs:domain [
a owl:Class;
owl:unionOf (… <PurchaseOrder_Object> …)];
rdfs:subPropertyOf <opal:RELATEDNESS>.
Relations in the Specific Section of the OPAL templates
The translation of the relations in the Object, Process, Actor Specific Sections, as well as the ones
in the Message, BOD and Operation Specific Sections, is performed by using the properties introduced
in the translation of the specific relations.
For each pair (ci,ck) in a given specific relation, the respective ObjectProperty is used.
For instance, GeneratedBy(PO,IssuingPO) is translated by using the GENERATED_BY
ObjectProperty. In the definition of the PurchaseOrder class, a Restriction on the range of this property
is added:
<PurchaseOrder_Object> a owl:Class;
…
rdfs:subClassOf [
a owl:Restriction;
onProperty <GENERATED_BY>;
allValuesFrom <IssuingPO_Process>].
The translation of the relations in the ComplexAttribute and AtomicAttribute Specific Sections is
performed by using the OWL modeling notions corresponding to the respective specific relations, as
indicated previously. For instance, in the PO example kind(OrderLine) = CA and in its Specific Section
we have domain(OrderLine) = {PurchaseOrder, Invoice} and Functional(OrderLine) = true.
Since these constraints are global, the Object Property “has_OrderLine” is asserted as Fuctional
and its domain is the union of the PurchaseOrder_Object and Invoice_Object classes:
<has_OrderLine>
a FunctionalProperty ;
rdfs:domain [
a owl:Class;
owl:unionOf (<PurchaseOrder_Object> <Invoice_Object>)].
For what concerns the Atomic Attributes, in the PO example kind(ItemId) = AA and in its Specific
Section we have range(ItemId) = {String}.
In the definition of the OWL datatype property representing the attribute, the following assertion is
added:
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 171 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
<hasPart_ItemId>
rdfs:range <xsd:String>.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 172 / 244
IP- Project
ATHENA - Project
Document
8
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Conclusions to the Athos Representational Specifications
In this first part of the document we addressed the problem of supporting the domain experts, with
limited ontology engineering knowledge, in the ontology building activities. Our work starts from the
assumption that ontology languages, such as OWL, are not easy to use and adding domain specific
modeling notions (that does not imply greater expressive power) provides a helpful solution. The
proposed method is aimed at the introduction of domain specific modeling notions in the
representation framework. Therefore we presented OPAL, an ontology framework that includes a few
basic notions drawn from business modeling domain.
In particular, the primary concept categories identified are: Object, Process, and Actor. The
domain expert, during the ontology modeling process, is required to identify the relevant concepts of
the domain and to classify them according to OPAL categories.
Furthermore, a set of semantic relations (such as is-a, part-of, relatedness) and some domain
specific relations (generated-by, updated-by, roles, skills, etc.) can be used to describe the
relationships among these concepts.
We presented a first axiomatization of OPAL, aimed at a better understanding of its semantics.
The axioms are represented by a set of constraints defined over the semantic relations. On a more
practical ground, the axioms are used to supporting the verification, for an enhanced quality of the
produced ontology.
In OPAL the structure of concepts is based on a Frame-Slot-Facet paradigm. In particular, the
proposed frame structure (template) is organised in three sections: Identification, Structural, Specific
Section.
These sections have been presented with an algebraic approach that can be seen as the abstract
syntax of the representation language. The concrete syntax is currently OWL, with a few extension
derived from the OPAL approach. Therefore, semantics of the language is expressed by using an
axiomatic approach: we map the OPAL model to OWL.
The OPAL ontology framework has been used in building the Athos ontology management
system. Athos, an open source system implemented on top of the Zope platform, has been developed
within the European Integrated Project Athena and is currently under experimentation. The first results
indicate that the proposed method is well accepted by business people and its supporting features
have been recognised. An extensive use of Athos is planned in the next period and we expect
significant feedbacks to further improve the system and the OPAL ontological framework.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 173 / 244
IP- Project
ATHENA - Project
Document
9
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
The Athos functional and architectural specifications
In the previous sections, the representational specifications of Athos have been presented.
Essentially the OPAL specifications have been provided. In the next sections of the document, the
attention will be focused on the functional and architectural aspects.
9.1
Requirements and specifications
In the next table a list of requirements for the development of the Athos has been considered. This
list has been derived from the requirements identified in the SoA, in the section about the tools for
ontology management.
For each requirement, a corresponding solution provided in Athos is described.
1
System Requirements
Web orientation, in order to be used
remotely, without needing any specific client
4
Controlled access to an ontology
5
Different views and working modes.
Usually the first step in building an
ontology is to identify a glossary of the
relevant terms that characterize the
domain of interest
System specifications
•
Athos has been developed as a web
application;
•
It is accessible remotely;
•
It needs just a web browser as a client
(thin-client);
•
The user interface is composed by dynamic
HTML pages (light-weight client)
•
Athos provides user management
functionalities;
•
Users can access the system if provided of
a registered account;
•
Three different types of users:
o Ontology Master, with the complete
responsibility on the ontology;
o SuperUser, with the capability of
proposing modifications to the ontology.
Such modification need to be accepted by
the Ontology Master;
o SimpleUser, with the only reading rights.
Athos provides two working modes:
•
Glossary, only the Identification section of
each concept is shown (the relations are
hidden)Ontology, all the relations are
shown and can be edited
These terms will be then used in the
definition of the concept in the ontology
Building a glossary is an activity that
involves less information than an ontology
(no relations are involved)
Guided definition of a concept
•
•
Ontology navigability
•
•
•
050404_ATHENA_DA31_PartB_V10.doc
Athos provides a user-friendly interface for
a stepwise definition of an ontology.
The user interface is based on forms
structured in accordance with the OPAL
templates.
An ontology represents a semantic net
where concepts are the nodes and the
relations between concepts represents
semantic links
Athos shows such links in a clear way and
allows to traverse them in an efficient way
Navigability among concepts is also
supported by an efficient query functionality
CONFIDENTIAL
Page 174 / 244
IP- Project
ATHENA - Project
Document
3
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
Ontology consistency checking
Keeping track of the work (who does what)
A built-in module for the checking of the
OPAL constraints has been developed;
•
Validation and verification of absence of
other contradictions is demanded to
external tools to be integrated into the
system or accessible as web services.
Athos provides a log functionality in order to:
•
•
•
Keeping track of the documental resources
•
•
Report production
•
•
Web services support
•
•
Extendibility of functionalities
•
050404_ATHENA_DA31_PartB_V10.doc
507849
A3
04.04.05
•
•
Knowledge export
IP- Project - No
ATHENA - Project Number
Date
Record all the activities regarding an
ontology to be re-used for restoring data;
Monitoring the access to an ontology to be
used for statistics
At the time being, Athos allows an OWL
export. Import from of OWL is going to be
developed.
Import/export from/to other languages will
be part of future extensions
Definition of concepts need to be supported
by evidences.
Athos allows to store the documental
resources that have been used for the
definition of single concepts
Once an ontology has been built, but also
during the building activity, it can be
relevant to provide reports on the ontology
At the time being Athos provides some
reports such as:
o Extraction of the glossary
o Definition of a concept
o Summary of the ontology
Reports can be saved and printed
Athos supports web services at two levels:
o It exposes some functionalities as web
services (Athos as a server)
o It is enabled to access existing web
services (Athos as a client)
Athos provides a plug-in architecture in
order to ease future extensions and to
develop new functionalities.
CONFIDENTIAL
Page 175 / 244
IP- Project
ATHENA - Project
Document
10
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
507849
A3
04.04.05
System Architecture
Athos has been developed as a web application. Its architecture has been organised according to
a three-tier organization (Figure 3)
•
the Client-tier represents the layer where the Athos clients run. Athos provides two ways to
access its ontology management functions. Through a common web browser (thin client) with a
Graphical User Interface (GUI), and through a set of XML-based APIs, exposed as web services,
for the interoperability with other systems;
•
a middle tier (Application tier) where the ontology management logic is implemented.
•
a back-end (Database tier) where concepts are stored and managed.
Other
systems
Athos
GUI
HTTP
SOAP
Internet
Client
tier
Athos
Validation
tool
Client Manager
Application Logic
SOAP
Figure 3.
Ontolo
Ontolo
gies
gies
Reporting
tool
(Web Services)
Athos DBs
Users
Users
admin
admin
Diagramming
tool
Other
system
DB AccessMngr
Database
tier
Internet
WS connector
Server
tier
Instan
Instan
ces
ces
Log
Log
The Athos macro-architecture
10.1 The Athos GUI
The Athos Graphical User Interface (Figure 4) is based on Web technologies. It is a light-weight
client application usable through a Web browser (in its first version only Internet Explorer). It is
organized as a set of forms that allow the ontology content to be managed. The GUI shields the
complexity of the OPAL meta-model behind, supporting a step-wise concept definition. Furthermore it
is adaptive, in the sense that, the available functions depend on the user’s access right.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 176 / 244
IP- Project
ATHENA - Project
Document
Figure 4.
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
The Athos GUI
10.2 The Application tier
The Server tier contains all the system functions. It is composed by three modules, the Client
Manager, the Application Logic and the Database Access Manager
10.2.1 The Client Manager
The Client Manager (Figure 5) is the sub-module of Athos that manages the communication
between the Application Logic and any Athos client. Athos provides a web-browser graphical user
interface, but it should allow other applications to access to its ontology management. For this reason,
some of the Athos functionalities are exposed as web services.
•
•
•
The Client Manager module is in charge to:
accept the requests from a client and return the result to the client itself. These tasks are
performed by the Athos gateway;
manage the user sessions maintaining the information about the currently connected users and
recognizing them at each interaction. This task is performed by the Sessions Manager;
redirect the requests coming from the clients to the Application Logic. This task is provided by the
Communication System. If a request comes from the Athos GUI, the Communication System
invokes the functionality of the GUI Generator (the sub-module in charge to produce the dynamic
HTML pages). Depending on the request, a specific form, containing the requested data, is
dynamically generated. On the other hand, if the request comes from another application, through
the invocation of the Athos web services, by using the SOAP protocol, it is firstly managed by the
SOAP support. This module converts the request from a SOAP request into a platform specific
call (in this case in a Zope/Python call). Then the request is sent to the Application Logic and the
result are sent back to the requestor as a SOAP response. This case does not involve the GUI
Generator module, since the request does not come from the Athos GUI.
10.2.2 The GUI Manager
The GUI Manager is the sub-module that coordinates the components of the Athos GUI. It
dynamically generates the forms to be shown to the user starting from the data.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 177 / 244
IP- Project
ATHENA - Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
Web browser
(Athos GUI)
HTTP
507849
A3
04.04.05
Other Systems
(SOAP clients)
Internet
SOAP
Client Manager
Athos gateway
SOAP
support
Sessions
Manager
GUI
Generator
HTML
pages
Page
Templates
Figure 5.
Page data
Communication
System
Application Logic
The Client Manager
10.2.3 The Application Logic Module
The Application Logic Module (Figure 6) implements the application functions. In particular it is
composed by
•
The Admin Manager that manages the administration functions of the system, such as “identify
the user at the login time”, “create a new user account”, and so on;
•
The Ontology Manager that provides the ontology management functions, such as “create a new
concept”;
•
The Consistency Checker that, before performing an update operation on the ontology, verifies
that the modification will not violate any ontology constraints. These constraints are defined
according to the OPAL methodology;
•
The Import/Export module that provides the ontology content export that will be taken in input by
the Semantic Mapping tool. Further it allows the import of concepts4;
•
The Error Manager that is in charge to manage the system errors (e.g. a database error) and the
application exceptions (e.g., the violation of an ontology constraint);
•
The Query Processor module that is in charge to resolve the semantic query.
4
At the moment the OWL export function has been implemented..
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 178 / 244
IP- Project
ATHENA - Project
Document
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
507849
A3
04.04.05
Client Manager
Request Dispatcher
Import/Export
module
Ontology Manager
Query
Processor
Application
Logic
Admin Manager
Error
Manager
Constraints Checking
Module
Database Connector
Figure 6.
The Application Logic
10.2.4 The Database Access Manager
This module provides the communication with the DBMS. All the functions exposed to the
Application Logic represent the Athos db connectivity API. They provide a higher level of abstraction to
interact with the database layer.
10.3 The Database tier
The Athos Database tier is composed by several databases each of them devoted to the storage
of specific information.
•
The Administration database stores the information about the user profiles and accounts and
general information about the existing ontologies;
•
An Ontology database exists for each domain ontology created in the system. It contains the
actual ontology content (concepts and relations between concepts);
•
A Log database for each existent ontology. It records the information about the action performed
by the users on each ontology;
•
An Instances database for each existent ontology in order to store the concepts instances.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 179 / 244
IP- Project
ATHENA - Project
Document
11
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
The Athos plug-in model
In organizing the architecture of Athos we tried to consider the possibility of having a mechanism
for allowing third parties to easily develop extensions to the system’s functionalities. This requirement
is based on the experience that no matter how many functionalities are included in the product, there
are always some special features needed by various users.
To meet the requirement we decided to adopt a plug-in based architecture.
In general, a plug-in (also referred as “add-on” or simply “extension”) is a piece of software that
can be "plugged into" a software system without any modification of this system; in particular:
•
it is automatically recognized by the system it is plugged into;
•
it starts offering the service it was projected for inside the “hosting” system.
Usually plug-in based frameworks requires newly-created extensions to satisfy some specific
constraints, but no restrictions is given, at design time, of what type of functionality this plug-in can
offer.
In this section first we will briefly describe the most interesting (from the perspective of Athos)
State-of-the-Art plug-in based architectural solutions; we analyzed the extension capabilities of
Protegè, one of the most famous ontology management systems, and the plug-in framework of
Eclipse, because we think it should be considered a reference model for every plug-in based
architecture thanks to its robust organization. After that the Athos Plugin framework will be described
together with the plug-in structure of the actual version of Athos. Finally we will expose the procedure a
developer must follow, in order to project an extension (a plug-in) to Athos.
11.1 The Eclipse plug-in model
Eclipse5 is an extensible platform for building IDEs. This extensibility is provided by wrapping new
modules in pluggable components, called Eclipse plug-ins, which have to conform to the Eclipse’s
plug-in contract. The basic mechanism of extensibility in Eclipse is that the new plug-ins can add new
processing elements to existing plug-ins, while Eclipse provides a set of core plug-ins to bootstrap this
process.
In the Eclipse model, a plug-in may be related to another plug-in by one of two relationships
(Figure 7):
•
Dependency: the roles in this relationship are dependent plug-in and prerequisite plug-in. A
prerequisite plug-in supports the functions of a dependent plug-in;
•
Extension: the roles in this relationship are host plug-in and extender plug-in. An extender plugin extends the functions of the host plug-in.
Figure 7.
5
The Eclipse plug-in relationships and roles
http://www.eclipse.org/
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 180 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
The extension must conform to a unique set of configuration and behavioural requirements.
Therefore, an extensible plug-in provides different types of slots that extensions can plug into. These
slot types are called extension points (Figure 8).
In the context of a particular extension, a plug-in that stands in the host role provides the
extension-point and it is extended. In addition to providing services in its own right, such a plug-in also
acts as the coordinator and controller of a number of extensions.
On the other hand, a plug-in that stands in the extender role defines the extension, typically
making certain aspects of itself available to a host plug-in through the extension, and, in addition,
causing the host plug-in to add certain processing elements to its environment.
Figure 8.
Extension point
In simple cases, a single act of extension adds a single callback object to the environment,
through which the host and extender plug-ins communicate (Figure 9). The extension point specifies
the interface of the callback object (a Java interface that represents the specifications of the callback)
while the extension provides the implementation of such interface. The mechanism that allows the
communication between host and extender is based on the fact that the host activates the extender by
instantiating the corresponding callback.
Beside the real implementation of the Extension points and Extensions, essentially the interface
and the implementation of the callback object, both Extension points and Extensions are described in
an XML file, named plug-in.xml. This is a manifest file that, for each plug-in, describes both the
Extension points and the available Extensions. It is used by the developers as specification for
understanding how to implement an Extension and at start time of the system for verifying the
correctness of the Extensions respect to the Extension points.
Figure 9.
Callback object
11.2 The Protégé plug-in model
Protegè is designed to be extended by the following kinds of plugins: tab-widget plugins, slotwidget plugins, backend plugins, import or export plugin and project plugin.
•
A tab-widget plug-in is a user interface tab that appears in the main Protégé window beside the
system tabs such as the classes tab;
•
Slot-widget plug-in appears on a form and it is used to view and acquire a value for a slot at an
instance;
•
A backend plug-in is used to specify the mechanism that Protégé-2000. will use for storage
(either as text or in a database);
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 181 / 244
IP- Project
ATHENA - Project
Document
•
•
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
507849
A3
04.04.05
An import or export plug-in is used for executing translations between different formalisms;
Project plug-ins support the project life-cycle.
Protegè can so easily extended by extending the appropriate (furnished) java classes; for example
to have a new tab you have to subclass AbstractTabWidget and implement the "initialize()" method.
11.3 Athos plugin framework
In developing the Athos plugin architecture we tried to gather influences from the above described
frameworks and in particular from the Eclipse plug-in model.
•
•
•
•
•
•
Figure 10 describes the final Athos plug-in framework architecture:
Plugins can use one or more Core Ontology Services to realize their own service; The Core
Ontology Services are the basic functionalities regarding the management of an ontologies,
namely, inserting, updating, deleting and retrieving concepts of a particular ontology;
Plugins can depend on other plug-ins for working properly (requiring them to be installed in the
system as well);
An Extension Plug-in is a piece of software that extends the functionality of the system; it must be
connected, through a process called Plug-in registration (described later in this document), to the
ZExtension point of a Host Plug-in; the same plug-in can have contemporarily the Host and an
Extender role;
A ZExtension Point can be thought as a container in which all the connected (Extender) plug-ins
can be found. The exact range of contained objects can be specified using the
Connection_Cardinality attribute. For example, we could want the ZExtension Point to contain not
more than 3 extensions or exactly 1;
A ZExtension Point is described by a ZExtension Point Description, that is a XML file describing
the interface the Extender Plug-in must implement in order to be able to be connected to the
ZExtension Point;
Host plug-ins expose 0 or more ZExtension Point such as Extender plug-ins can be connected to
0 or more ZExtension point. The same plug-in connected to two different ZExtension points can
behave differently in each of the two.
depends on
*
Core Service *
uses
*
Plug-in
*
Host Plug-in
Extender Plug-in
1
1
exposes
*
ZExtension Point
isConnectedTo
*
1
isDescribedBy
1
ZExtension Point Description
Figure 10.
The Athos plug-in Framework
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 182 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
11.3.1 ZExtension Point Description
A ZExtension Point Description is represented by an XML file.
Essentially it describes the “needs” of a Host Plug-in in terms of methods to be implemented, input
and output.
In writing Plug-ins that want to be hosted by must conform to such requisites.
See below for the XMLSchema of the ZextensionPointDescription.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="ZExtensionPointDescription">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="method">
<xs:complexType>
<xs:sequence>
<xs:element name="input">
<xs:complexType>
<xs:attribute name="parName" type="xs:string"
use="required"/>
<xs:attribute name="type" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="output">
<xs:complexType>
<xs:attribute name="type" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
Here’s minimal example of such a file:
<?xml version=”1.0” encoding=” ISO-8859-1”?>
<ZExtensionPointDescription name=“InfoCollector”>
<method name=“getInfo”>
<input parName=“ontology” type=“OPALOntology”>
<output type=“list”>
</method>
</ZExtensionPointDescription>
The above describes a ZExtension point called InfoCollector; a plug-in capable of being
connected to InfoCollector must implement a method called getInfo that receives in input the
“ontology” parameter (having type “OPALOntology”) and returning as result an object of type “list”.
11.4 The Athos Plug-in development
Since Athos is based on the Zope platform, plug-ins for the Athos system must be Zope compliant
Python classes. The instances of such classes, must be capable of being stored in the ZODB.
Please refer to the Zope Book or Zope DevGuide for further details on how to realize Zope
compliant products.
All Athos plug-in must extend a base superclass called Plugin.
In addition Athos add-ons must implements the interfaces of the ZExtension Point they want to be
connected to.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 183 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
11.5 Plug-ins registration
Once an extension to Athos has been projected it must be integrated in the system.
The process of connecting an Extender plug-in to a ZExtension Point is called Plug-in registration.
In the above described frameworks (Protegè, Eclipse) a similar process is obtained by copying the
folder containing the new add-on in a special folder in the program distribution; the application is then
restarted, the new plug-ins are automatically recognized and, if all works, they are integrated in the
system. The (Extension point , Extender) pairs are statically described by XML files.
In Athos we benefit of the “object persistence” realized by the ZODB (the Zope Object DB) in
order to avoid to recompile and restart the application; newly created plug-ins are connected to a
specific ZExtension Point at run-time using the methods of the ZExtension Point instance.
Exploiting Zope web functionality, the process of registration can be conveniently done by using a
web interface (as well as other kinds of web clients via WebDAV, HTTP, FTP, XML-RPC, SOAP);
Figure 11 and Figure 12 show the Web interface for the registration of the plug-ins; the Host
Plugin “ConceptRelations” expose two ZExtension Point’s (Figure 11) and the first of those point
contains two Extender plugins (Figure 12).
To register a new plug-in the button “import/export” should be used to import the plug-in from the
local filesystem.
The other web GUI buttons can be used to realize cut and paste operations on plug-ins; in
particular deleting a plug-in it will be unregistered from the ZExtension point and its functionality will be
automatically removed from the Athos system.
•
•
•
In registering a plug-in, the following cases are given:
Failure: The plug-in can not be registered because it doesn’t conform to the ZExtension Point
interface;
Failure: The plug-in can not be registered due to the cardinality restrictions of the ZExtension
point (for example number of possible extensions for that point exceeded);
Success: The plug-in is effectively registered and starts offering its service in the system
immediately.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 184 / 244
IP- Project
ATHENA - Project
Document
Figure 11.
IP- Project - No
ATHENA - Project Number
Date
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
507849
A3
04.04.05
Plug-in registration – two ZExtension Points
Two Extender Plug-ins
Figure 12.
Plug-in registration – two Extender plug-ins
11.5.1 Athos plug-in map
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 185 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Athos Gui
ConceptInfo
MenuBar
RelationView
Navigation Bar
ConceptList
Figure 13.
Specialisation Hierarchy
Decomposition Hierarchy
Search
The Athos plug-in map
In Figure 13, we find the (macro) plug-in structure of the actual version of the GUI of the Athos
OMS.
•
•
•
•
The whole GUI is subdivided into 4 main components:
A MenuBar;
A Navigation (tabbed) bar;
A panel for presenting the selected concept information summary;
A panel for presenting the selected concept involvement in relations.
Each of the above components is a plug-in connected to the ZExtension Point of the Host plug-in
Athos Gui; further plug-ins can be developed and connected to Athos Gui to realize a more complex
user interface.
Recursively, each of the subcomponents is a Host plug-in and can be customized by connecting
to it new extensions: new menus in the menu bar, new tabs in the navigation bar etc.
•
•
•
•
The navigation bar actually is extended by:
Concept list: a plug-in that uses ontology core services to get the list of the actually defined
concepts in the current ontology and presents them using an interactively sortable table widget;
Specialisation hierarchy: a plug-in that uses ontology core services to construct the specialization
hierarchy of the current ontology and presents it using Tree widget;
Decomposition hierarchy: same as the precedent one for decomposition hierarchy;
Search: a little engine to search among the ontology concepts.
Though we described here only the GUI plug-in structure, that realizes the presentation logic of
Athos, plug-ins can be added also to expand the application logic functionalities of the system.
In future we plan to continue the development of plug-ins to extend the system functionalities like,
for example, more refined (semantic) search techniques and ontology validation by using connection
with external reasoning tools.
11.5.2 How to develop a new Athos plug-in
•
Choose the ZExtension Point’s you want to extend;
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 186 / 244
IP- Project
ATHENA - Project
Document
•
•
•
•
•
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Write Zope compliant code (python) extending the base class Plugin and implementing the
interfaces of the ZExtension Point Description;
If your plug-in is also a Host, write the ZExtension Point Description xml file (in future will be
automatically generated);
(Recommended) Test your plug-in in a separate environment;
Register your plug-in in the appropriate ZExtension Point by using the apposite web interface (or
the client you prefer);
The plug-in is now integrated in the Athos system.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 187 / 244
IP- Project
ATHENA - Project
Document
12
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Athos web services
Athos has been conceived as a web application. It has been provided of a GUI usable through a
web browser. This feature allows human beings to access the system and use it.
Furthermore, in order to allow external application to use it some of the functionalities of the
system have been published as web services.
12.1 Introduction to web services
A Web Service is programmable application logic accessible using standard Internet protocols.
Web Services combine the best aspects of component-based development and the Web. Like
components, Web Services represent black-box functionality that can be reused without worrying
about how the service is implemented. Unlike current component technologies, Web Services are not
accessed via object-model-specific protocols, such as DCOM, RMI, or IIOP. Instead, Web Services
are accessed via ubiquitous Web protocols (ex: HTTP) and data formats (ex: XML).
Essentially the main technologies involved in the specification, implementation and usage of web
services are:
•
XML: The Extensible Markup Language is a text-based mark-up language specification from the
World Wide Web Consortium (W3C). Unlike HTML, which uses tags for describing presentation
and data, XML is strictly for the definition of portable structured data. It can be used as a
language for defining data descriptive languages, such as mark-up grammars or vocabularies
and interchange formats and messaging protocols;
•
SOAP: Simple Object Access Protocol is an XML-based lightweight protocol for the exchange of
information in a decentralized, distributed environment. SOAP defines a messaging protocol
between requestor and provider objects, such that the requesting objects can perform a remote
method invocation on the providing objects in an object-oriented programming fashion. The
SOAP specification was co-authored by Microsoft, IBM, Lotus, UserLand, and DevelopMentor.
The specification subsequently spawned the creation of the W3C XML Protocol Workgroup.
SOAP forms the basis for distributed object communication in most vendor implementations of
SOA. Although SOA does not define a messaging protocol, SOAP has recently been referred to
as the Services-Oriented Architecture Protocol due to its common use in SOA implementations.
The beauty of SOAP is that it is completely vendor-neutral, allowing for independent
implementations relative to platform, operating system, object model, and programming
language. Additionally, transport and language bindings as well as data-encoding preferences are
all implementation dependent;
•
WSDL: The Web Services Description Language is an XML vocabulary that provides a standard
way of describing service IDLs. WSDL is the resulting artifact of a convergence of activity
between NASSL (IBM) and SDL (Microsoft). It provides a simple way for service providers to
describe the format of requests and response messages for remote method invocations (RMI).
WSDL addresses this topic of service IDLs independent of the underlying protocol and encoding
requirements. In general, WSDL provides an abstract language for defining the published
operations of a service with their respective parameters and data types. The language also
addresses the definition of the location and binding details of the service;
•
UDDI: The Universal Description, Discovery, and Integration specification provides a common set
of SOAP APIs that enable the implementation of a service broker. The UDDI specification was
outlined by IBM, Microsoft, and Ariba to help facilitate the creation, description, discovery, and
integration of Web based services. The motivation behind UDDI.org, a partnership and
cooperation between more than 70 industry and business leaders, is to define a standard for B2B
interoperability.
In this first design of Athos, only search and retrieval functions have been exposed as web
services. In particular they are:
•
Query an Ontology: given a search criteria, returns a set of pairs, composed by label and kind,
corresponding to the concepts that match the search criteria;
•
Retrieve a whole ontology: all the concepts and relations between concepts regarding a given
ontology are retrieved;
•
Retrieve a Concept: given a label and a kind the corresponding Concept, if exists, will be
returned;
•
Retrieve the Specialization Hierarchy: returns the specialization hierarchy;
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 188 / 244
IP- Project
ATHENA - Project
Document
•
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Retrieve a Relation: given a label and a kind (identifying a concept), and a type of OPAL
relation, it returns all the concepts that are linked to the given concept through that relation.
See the Appendix A for two excerpts from the WSDL document concerning the description of the
Athos web service (OntologySrv) and in particular the getConcept and the search operations.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 189 / 244
IP- Project
ATHENA - Project
Document
13
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Zope: A Web Publishing Framework
Ahos has been developed under the Zope platform. Zope is an open source web-application
server and toolkit, written in and customizable with Python. It is a server-side technology that allows
web designers to implement sites and web applications by publishing Python object hierarchies on the
Web.
Using Zope, programmers can focus on writing application, and let Zope handle most of the
underlying HTTP and CGI details.
Zope is made freely available (and its code is Open Source) over the Internet by
Corporations and enjoys a large and very active development community
Zope
13.1 Zope Components
Zope began life as a set of tools placed in the public domain by a company called Digital
Creations. Since then, it has grown into a large system with many components, with continuously
newly-produced add-ons (called "products" in Zope language).
In terms of core components, Zope includes the following parts:
13.1.1 ZPublisher
At the heart of Zope, the ZPublisher, a kind of lightweight Object Request Broker. The ZPublisher
uses the request URL as a map to locate the published object. Finding an object to handle the request
is called traversal , since the publisher moves from object to object as it looks for the right one. Once
the published object is found, the publisher calls a method on the published object, passing it
parameters as necessary. The ZPublisher uses information in the request to determine which method
to call, and what parameters to pass. The process of extracting parameters from the request is called
argument marshalling . The published object then returns a response, which is passed back to Zope's
web server. The web server, then passes the response back to your web browser.
13.1.2 HTML document templates
Zope provides a simple way to define web pages as templates, with values automatically inserted
from Python objects. Templates allow an object's HTML representation to be defined independently of
the object's implementation. For instance, values of attributes in a class instance object may be
automatically plugged into a template's text by name. Template coders need not be Python coders,
and vice versa.
Actually two languages are available for the development of templates: DTML, getting obsolete,
and Zope Page Templates (ZPT); the code written in ZPT is legal HTML so that it can be edited using
a HTML editor (that’s not true for all template languages).
13.1.3 Object database (ZODB)
To record data persistently, Zope comes with a full object-oriented database system for storing
Python objects. The Zope object database is based on the Python pickle serialization (a module used
to serialize python objects), but adds support for transactions, lazy object fetches (sometimes called
delayed evaluation), concurrent access, and more. Objects are stored and retrieved by key, but
necessary condition for an object to be stored in the ZODB is that the correspondent classes must
subclass an imported Persistent superclass, and object stores are instances of an imported
PickleDictionary object.
Zope starts and commits transactions at the start and end of HTTP requests.
Zope also includes a management framework for administrating sites, as well as a product API
used to package components.
Zope ships with these and other components integrated into a whole system, but each part can be
used on its own as well.
For instance, the Zope object database can be used in arbitrary Python applications by itself.
13.2 Why Use Zope Instead of Another Application Server
Zope is free of cost and is distributed under an open-source license. There are many non-free
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 190 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
commercial application servers that are relatively expensive.
Zope itself is an inclusive platform. It ships with all the necessary components to begin developing
an application. It is not needed any license of extra software to support Zope (e.g. a relational
database) in order to develop your application. This also makes Zope very easy to install. Many other
application servers require to configure complex third-party infrastructure software before you can
begin to develop your application.
Zope allows and encourages third-party developers to package and distribute ready-made
applications. Due to this, Zope has a wide variety of integrated services and add-on products available
for immediate use. Most of these components, like Zope itself, are free and open source. Zope's
popularity has bred a large community of application developers. Many other application servers do
not have a large base of third-party support or a means for so neatly packaging plug-ins.
Applications created in Zope can scale almost linearly using Zope's Zope Enterprise Objects
(ZEO) clustering solution. Using ZEO, you can deploy a Zope application across many physical
computers without needing to change much (if any) of your application code. Many application servers
don't scale quite as transparently or as predictably.
Zope allows developers to create web applications using only a web browser. The Internet
Explorer, Mozilla, Netscape, OmniWeb, Konqueror, and Opera browsers are all known to be able to be
used to display and manipulate Zope's development environment (the Zope Management Interface
also known as the ZMI ). Zope also allows developers to safely delegate application development
duties to other developers "through the web" using the same interface. Very few other application
servers, if any, deliver the same level of functionality.
Zope provides a granular and extensible security framework. You can easily integrate Zope with
diverse authentication and authorization systems such as LDAP, Windows NT, and RADIUS
simultaneously, using prebuilt modules. Many other application servers lack support for some
important authentication and authorization systems.
Zope allows teams of developers to collaborate effectively. Collaborative environments require
tools to allow users to work without interfering with each other, so Zope has Undo , Versions , History
and other tools to help people work safely together and recover from mistakes. Many other application
servers do not provide these kinds of features.
Zope runs on most popular operating system platforms: Linux, Windows NT/2000/XP, Solaris,
FreeBSD, NetBSD, OpenBSD, and Mac OS X. Zope even runs on Windows 98/ME (recommended
only for development purposes, however). Many other application server platforms require that you run
an operating system of their licensor's choosing.
Zope can be extended using the interpreted Python scripting lanuage. Python is popular and easy
to learn, and it promotes rapid development. Many libraries are available for Python which can be used
when creating your own application.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 191 / 244
IP- Project
ATHENA - Project
Document
14
•
•
•
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Conclusions and Future Work
In this report we have described the Athos design guidelines. They have been conceived for:
A client server architecture with three tiers. This architectural schema allows to maintain
separated and independent different aspects of the system such as the client side, the server
side and the database management.
Highly scalability. This feature allows to add and modify system functionality with a minimum
impact on the rest of the architecture. This feature is supported both by the characteristics of
Zope and by the Athos plug-in model
The Athos system is accessible through a browser. This is a very important feature because it
allows to use Athos potentially from everywhere.
On the other side, the future activity will be in particular concentrated on the reporting,
diagramming of ontologies and query functionalities.
Furthermore, the consistency checks will be improved.
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 192 / 244
IP- Project
ATHENA - Project
Document
15
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
Appendix A
Two excerpts from the WSDL document concerning the description of the Athos web service
(OntologySrv) and in particular the getConcept and the search operations.
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://athos">
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<!— Definition of a simplified structure of an OPAL concept -->
<complexType name="Concept">
<sequence>
<element name="label" nillable="true" type="xsd:string"/>
<element name="kind" nillable="true" type="xsd:string"/>
<element name="description" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</schema>
</wsdl:types>
<!— Definition of the message to be used as return parameter -->
<wsdl:message name="getConceptResponse">
<wsdl:part name="getConceptReturn" type="tns2:Concept"/>
</wsdl:message>
<!— Definition of the message to be used as input parameter -->
<wsdl:message name="getConceptRequest">
<wsdl:part name="label" type="xsd:string"/>
<wsdl:part name="kind" type="xsd:string"/>
</wsdl:message>
<!— Definition of the service and the getConcept operation -->
<wsdl:portType name="OntologySrv">
<wsdl:operation name="getConcept" parameterOrder="label kind">
<wsdl:input name="getConceptRequest"
message="impl:getConceptRequest"/>
<wsdl:output name="getConceptResponse"
message="impl:getConceptResponse"/>
</wsdl:operation>
</wsdl:portType>
------------------------------------------------------------------------------------------------------------------------<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://athos">
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<!— Definition of the structure that identifies a concept -->
<complexType name="ConceptHeader">
<sequence>
<element name="kind" nillable="true" type="xsd:string"/>
<element name="label" nillable="true" type="xsd:string"/>
</sequence>
</complexType> <wsdl:types>
<!— Definition of the message to be used as return parameter -->
<wsdl:message name="searchResponse">
<wsdl:part name="searchReturn"
type="impl:ArrayOf_tns2_ConceptHeader"/>
</wsdl:message><!— Definition of the message to be used as input
parameter -->
<wsdl:message name="searchRequest">
<wsdl:part name="criteriaType" type="xsd:string"/>
<wsdl:part name="criteriaData" type="xsd:string"/>
</wsdl:message><!— Definition of the service and the search operation --
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 193 / 244
IP- Project
ATHENA - Project
Document
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
> <wsdl:portType name="OntologySrv">
<wsdl:operation name="search" parameterOrder="criteriaType
criteriaData">
<wsdl:input name="searchRequest" message="impl:searchRequest"/>
<wsdl:output name="searchResponse" message="impl:searchResponse"/>
</wsdl:operation> </wsdl:portType>
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 194 / 244
IP- Project
ATHENA - Project
Document
16
ATHENA
Knowledge Support and Semantic Mediation Solutions
Deliverable A3.1 Part B
IP- Project - No
ATHENA - Project Number
Date
507849
A3
04.04.05
References
[1] D.L.McGuinness, R.Fikes, J.Hendler, L.A.Stein. DAML+OIL: An Ontology Language for the Semantic Web
. In IEEE Intelligent Systems, Vol. 17, No. 5, pages 72-80, Sept.2002
[2] F.van Harmelen, I.Horrocks, P.F.Patel-Schneider, OWL Web Ontology Language Semantics and Abstract
Syntax, W3C Candidate Recommendation 18 August 2003
[3] J.Heflin, J.Hendler, S.Luke; SHOE: A Knowledge Representation Language for Internet Applications,
Technical Report CS-TR-4078 (UMIACS TR-99-71). 1999.
[4] M. Minsky, Frame-system: Theory in Thinking, University Press, London, 1977.
[5] M.Missikoff, F.Taglino; Symontox: A Web-Ontology Tool for eBusiness Domains; Proc. of WISE2003,
Roma-Italy, Dec 2003.
[6] Noy, N.F., Fergerson, R.W., and Musen, M.A. The knowledge model of Protege-2000: Combining
interoperability and flexibility. Proc. EKAW 2000.
[7] Y. Sure, M. Erdmann, J. Angele, S. Staab, R. Studer, and D. Wenke. OntoEdit: Collaborative ontology
engineering for the semantic web. In International Semantic Web Conference 2002 (ISWC 2002), Sardinia, June
2002.
[8] OMG Group. Unified Modeling Language (UML), version 1.5. Available on-line:
http://www.omg.org/technology/documents/formal/uml.htm.
[9] http://www.rosettanet.org
[10] Business Process Modeling Language (BPML). Alameda (CA): Business Process Management Initiative,
2001. Working Draft 0.4
[11] ebXML Business Process Specification Schema. Version 1.01. OASIS and UN/CEFACT, 2001. Accessed
2002-04-11 2002. Available from http://www.ebxml.org/specs/ebBPSS.pdf
[12] OAGIS: A 'Canonical' Business Language Providing both Vertical and Horizontal Requirements." By
Michael Rowell (Chief Architect, Open Applications Group). Version 1.0. White Paper, 2002.
[13] Unified Modeling Language (UML), version 1.5, 2003. Available at:
http://www.omg.org/technology/documents
[14] Farquhar, A.; Fikes, R.; & Rice, J. The Ontolingua Server: A Tool for Collaborative Ontology Construction.
Knowledge Systems Laboratory, September, 1996
[15] S. Handschuh, A. Maedche, L. Stojanovic and R. Volz, The KArlsruhe ONtology and Semantic Web
Infrastructure: White Paper, Forschungszentrum Informatik FZI, http://www.fzi.de/wim, Institute AIFB,
University of Karlsruhe, http://www.aifb.uni-karlsruhe.de/WBS
[16] Jeff Z. Pan and I. Horrocks. RDFS(FA) and RDF MT: Two Semantics for RDFS. In Proceedings of the 2nd
International Semantic Web Conference (ISWC2003).
[17] D. Nardi, R. J. Brachman. An Introduction to Description Logics. In the Description Logic Handbook, edited
by F. Baader, D. Calvanese, D.L. McGuinness, D. Nardi, P.F. Patel-Schneider, Cambridge University Press,
2002, pages 5-44.
[18] Eric S. K.Yu and John Mylopoulos. From E-R to “A-R” – modelling strategic actor relationships for
business process reengineering. In Proc. of the 13th International Conference on the Entity-Relationship
Approach – ER’94, Manchester (UK), December 13-16, 1994.
[19] Searle, J. Speech Acts: An Essay in the Philosophy of Language, Cambridge University Press, 1969
050404_ATHENA_DA31_PartB_V10.doc
CONFIDENTIAL
Page 195 / 244
Programme
Integrating and Strengthening the European Research
Strategic Objective
Networked business and government
Integrated Project / Programme Title
Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks
and their Application
Acronym
ATHENA
Project No
507849
ATHENA – Project Name
Knowledge Support and Semantic Mediation Solutions
ATHEN A - Project No
A3
DELIVERABLE D.A3.1
Title
SoA on Ontologies and the Ontology Authoring
and Management System, with Ontology
Modelling Language.
Part C: The Athos User Manual
Leading Partner: CNR-IASI
Security Classification: Project Participants (PP)
March 16th, 2005
Version 1.0
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 196 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Versioning and contribution history
Version
Description
0.1
First release
0.2
Internal review
1.0
Final version
Comments
Deliverable process schedule
No
1
Process step
Initial drafting of the deliverable
Responsible
including structure, comments and first F. Taglino (CNR)
basic content to be sent to to-be-
M.Missikoff (CNR)
Timing
Comments
05.07.2004
contributors.
2
3
First round of contributions. Work
F.Taglino (CNR)
package member and others to
D. Gazzotti
contribute first iteration to owner of
(Formula)
the deliverable
S-M Thomas (SAP)
Owner to consolidate first round input
and distribute to contributors
F. Taglino (CNR)
27.08.2004
22.10.2004
F.Taglino (CNR)
Final round of contributions including
4
comments form peers/AL to be sent to
owner
L. Pondrelli
(Formula)
S-M Thomas (SAP)
14.01.2005
E. Coscia (TXT)
F.W. Jaekel (IPK)
5
Final consolidation of input and
F. Taglino (CNR)
finalisation of “technical” document to
M. Missikoff (CNR)
be send to
G. Callegari (CNR)
28.01.2005
Only part B has been revised. We
6
Quality check – e.g. Peer Review
Elmar Dorner (SAP)
14.03.2005
didn’t receive any feedback for Part A
and B.
7
Final editing
Programme office
26.07.2005
PCC members or
8
Final Approval from partners or
delegates: Guy
delegates to be send to Programme
Dougmeings (itrec)
Office
Joerg Muller
21.03.2005
31.03.2005
(Siemens)
9
Submission to Commission
D.A3.1- Part 3 - Athos Manual V1.0
Programme
Committee
CONFIDENTIAL
Page 197 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Table of contents
1
Executive summary
203
1.1
Restriction of use
204
1.2
Access to the system
204
1.3
Disclaimer
204
2
Introduction
205
2.1
Definition of an Ontology
205
2.2
The Athos metamodel
206
2.2.1
OPAL meta-concepts
206
2.2.2
Athos concepts templates
207
2.2.3
Identification Section
208
2.2.4
Structural Section
208
2.2.5
Specific Section
208
2.3
Athos concepts references and use
211
2.3.1
Concepts list
211
2.3.2
Pending list
211
3
The Athos System
212
3.1
Generality
212
3.2
Athos User categories
212
3.3
Ontology users and group organisation
213
3.4
Athos Login
213
3.5
Athos Logout
215
4
The Athos Interface description
216
4.1
The Menu Bar
216
4.2
The Navigation Bar
217
4.3
The Concept List panel
218
4.4
The Identification Section panel
219
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 198 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
4.5
5
The Structural Section panel
220
Ontology User Functions
5.1
507849
221
Display a concept
222
5.1.1
The Identification Section
222
5.1.2
The Structural Section
223
5.1.3
The Specific Section
224
5.2
Display a concept specialisation hierarchies
225
5.3
Display a concept decomposition hierarchies
226
5.4
The search function
227
5.4.1
5.5
The search function activation
227
The glossary mode function
228
5.5.1
Glossary mode
228
5.5.2
Export glossary function
229
5.6
6
Print a concept
230
The Ontology Master Functions
6.1
231
Create a new concept
232
6.1.1
Input of the Identification Section
232
6.1.2
Input of the Structural Section
234
6.1.3
Input of the Specific Section
236
6.2
Example of creation of a new concept
237
6.3
Editing an existing concept
241
6.4
Deleting an existing concept
241
6.5
Pending terms management
242
7
INDEX
243
8
References
244
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 199 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figures
Figure 1.....Athos Template structure: a Business Object Document example......................207
Figure 2.....Login window......................................................................................................214
Figure 3.....Login page ...........................................................................................................215
Figure 4.....The Athos standard interface - Menu bar ............................................................216
Figure 5.....FigureThe Athos standard interface - Navigation bar .........................................217
Figure 6.....The Athos standard interface – Concept List ......................................................218
Figure 7.....The Athos standard interface – Identification Section ...............................................219
Figure 8.....The Athos standard interface – Structural/Specific Section.................................220
Figure 9.....The Ontology User Environment – Default display ............................................221
Figure 10...Display a concept: Identification Section ...................................................................222
Figure 11...Display a concept: Structural Section.......................................................................223
Figure 12...Display a concept: Specific Section...........................................................................224
Figure 13...Display the specialisation hierarchy ....................................................................225
Figure 14...Display the decomposition hierarchy ..................................................................226
Figure 15...The Search function.............................................................................................227
Figure 16...The Search Result ................................................................................................228
Figure 17...The Glossary display ...........................................................................................229
Figure 18...Export Glossary function.....................................................................................229
Figure 19...Glossary List........................................................................................................230
Figure 20...The Ontology Master environment......................................................................231
Figure 21...Creation of a new concept - The Identification Section .....................................233
Figure 22...Creation of a new concept - The Identification Section (cont’d)........................233
Figure 23...Creation of a new concept - The Structural Section ...........................................234
Figure 24...Creation of a new concept - The Structural Section(cont’d)..............................234
Figure 25...Creation of a new concept - Attribute addition ..................................................235
Figure 26...Creation of a new concept - Attribute addition (cont’d).....................................235
Figure 27...Creation of a new concept - Specific Section......................................................236
Figure 28...Creation of a new concept - Specific Section (cont’d) ........................................236
Figure 29...Creation of a new concept- Identification example............................................238
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 200 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 30...Creation of a new concept- Identification example (cont’d) ..............................238
Figure 31...Creation of a new concept- Structural example...................................................239
Figure 32...Pop-up window for the definition of a property ..................................................239
Figure 33...Creation of a new concept- Example of an Addition of an attribute ...................240
Figure 34...Creation of a new concept- Display of the inserted concept ...............................241
Figure 35...Editing an existing concept..................................................................................242
Figure 36...Editing an existing concept (cont’d)....................................................................242
Figure 37...Deletion of an existing concept.............................................................................242
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 201 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
1
507849
Executive summary
The User Manual of Athos has an organisation that aims at presenting in the first sections the
modelling philosophy of OPAL, which is at the base of the implementation choices and the user
interface of the system.
The main characteristics of the Athos system, that are reflected in the User Manual, are:
•
The modelling capabilities, based on OPAL, that are implemented in the GUI. To this end, the
OPAL representation method has been organised into a number of templates, that guides the
user in his/her modelling activities. A template is organised in three sections:
o Identification Section, that allows all the meta-data of the concept (name, author, XML tag, etc.)
to be introduced;
o Structural Section, that provides the constructors of OWL-DL, so that the user can define the
structural view of the concept (e.g., properties, hierarchies, constraints, etc.)
o “Kind” Specific Section. While the two previous sections are the same for all the meta-concepts
(referred to as kind in OPAL), this section is different for each kind, and contains a number of
properties and relationships that are meaningful to be defined in a business domain (this is the
key part that makes OPAL a business oriented ontology modelling method).
•
The usage modes. Two are the usage modes of Athos:
o Glossary mode: it allows for a simplified use of the tool. This modality is interesting for the
applications that don’t need a full fledged ontology or in the preliminary stages of the
production of a complex domain ontology;
o Ontology mode: this modality allows all the functions of Athos to be used, in order to build,
verify, inspect, and more in general manage a complex domain ontology.
•
The User Profiles. In Athos there are three user profiles that can be activated. The profiles are
described in ascending order, with respect to their privileges. It means that a profile with a higher
ranking inherits the privileges of the lower profiles. The profiles are:
o Ontology User: it allows any user, even with a limited ontology culture, to access the ontology
and inspect its content;
o Ontology Master: this profile is assigned for a specific ontology. It allows the user to access all
the functions that pertain to that ontology;
o Athos Admin: this is the higher profile, that allows the Admin to activate a new ontology, remove
an existing ontology, manage the users, etc.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 202 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
The Athos system presents a rich set of functionalities, that can be activated through the GUI. As
anticipated, not all the functions are available to all the profiles. Below a list of function categories is
reported, as seen by the Ontology Master (the Ontology User does not see functions that allow the
ontology content to be altered):
•
Defining concepts
•
Updating a concept
•
Deleting a concept
•
Viewing a concept
•
Viewing the ontology, in different forms:
o Alphabetic view
o Kind specific view
o Specialization hierarchy view
o Decomposition hierarchy view
•
Import/export of an ontology, or part of it.
•
Reporting
1.1
Restriction of use
Athos has been developed and released as a deliverable of the European ATHENA project A3,
Knowledge Support and Semantic Mediation Solutions. The Athos tool is released for use by the
authorized Athena project members for purposes linked to the Athena project objectives; any other
use outside this project should be authorized by the Athena Project management.
1.2
Access to the system
Athos functionalities can be accessed, via a common web browser, at the address http://leks-
pub.iasi.cnr.it/Athos. The browser must be enabled to accept cookies. Potential users must request in
advance access rights to the Athos Administration Center by e-mail. to: [email protected]
1.3
Disclaimer
Athos is released as a prototype software within an advanced research program; LEKS, IASI-
CNR cannot be held responsible for loss of data or information through potential malfunctions of the
released software, even if great care has been taken in Athos development and testing.
LEKS, IASI-CNR welcomes any information and suggestions that may improve the system.
Improvements and communications can be addressed to: [email protected]
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 203 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
2
507849
Introduction
The current document is the user guide of the Athos (Athena Ontology System), a software tool
developed by LEKS at IASI-CNR, for the definition and management of domain ontologies.
•
The current document is composed of the following chapters:
•
the current Chapter 2 – Introduction: provides a brief introduction to the concepts of an Ontology,
followed by the description of the modelling notions used by Athos and of the structure of the
Athos user interface;
•
Chapter 3 - Athos System: gives an outline of the Athos system, the different user profiles and
the description of the Login-Logout procedures that allow the access to the selected Athos
functionalities;
•
Chapter 4 - Athos Interface Description: describes the functionalities and the panels that
constitute a common structure of interaction and are available to all Athos profiles;
•
Chapter 5 – Ontology User Functions: describes the functions and the panels that are intended
for the normal User Profile;
•
Chapter 6 - Ontology Master Functions: describes the functions and the panels that are reserved
for the Ontology Master Profile;
2.1
Definition of an Ontology
An ontology represents a shared understanding of some domain of interest [2]. It entails some
sort of world view with respect to a given domain. It contains a set of concepts (e.g., representing
entities, attributes, processes), together with their definitions and their inter-relationships; this is also
referred to as a conceptualisation.
In other words, an ontology is an explicit, agreed specification about a shared conceptualisation.
An ontology may have different degrees of formality but, necessarily, it includes a vocabulary of terms
with their meaning (definitions) and their relationships.
According to [1], an ontology is a domain vocabulary containing a set of precise definitions, or
axioms, that:
•
provide the meaning of the terms,
•
enable a consistent interpretation of the terms defined in the vocabulary.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 204 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
2.2
507849
The Athos metamodel
A metamodel is a set of modelling notions, definitions and rules that allows the definition of a
conceptual model of a given domain. Therefore the metamodel allows one to specify which are the
information to be provided and the rules to be followed during the definition of concepts that constitute
an ontology.
The metamodel adopted in the Athos system is based on a subset of the OPAL methodology. For
sake of conciseness, such a methodology will not be recalled here entirely; only a brief description of
the OPAL modelling notions will be given in the following sections. A complete description of OPAL is
the object of the Part 2 of this deliverable.
2.2.1
OPAL meta-concepts
According to OPAL (Object, Process, Actor modeling Language), an ontology is constructed by
defining a set of concepts and establishing semantic relations among them. OPAL supplies a set of
predefined concept categories (referred to as metaconcepts) and semantic relations that form the
OPAL framework. The definition of a domain concept takes place by filling a concept template
(conceived according to a frame-slot-facet approach), supplying first the OPAL category it belongs to,
then the filling of the specified slots.
The OPAL categories, also referred to as kinds, are classified as Primary and Complementary,
according to the following prospect:
Primary Kinds:
•
Actor (Ar): aimed at modelling any relevant entity of the domain that is able to activate or perform
a process. (e.g. Buyer, Supplier);
•
Object (O): aimed at modelling a passive entity, on which a process operates, typically to modify
its state. (e.g., Purchase Order, Invoice);
•
Process (P): aimed at modelling an activity that is performed by an actor to achieve a given goal.
(e.g. Issuing Purchase Order, Sending Request for Quotation).
Complementary kinds:
•
Atomic Attribute (AA): represents an elementary information, such as “street name”;
•
Complex Attribute (CA): is defined as an aggregation of lower level CA and/or Atomic Attributes;
•
Message (M): describes the interaction between processes;
•
Business Object Document (BOD): represents the content of a message.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 205 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Other complementary meta-concepts, based on conditionals (e.g., State, Goal), are used to
complete the definition of Primary Concepts.
The OPAL concepts are connected by conceptual relations.
2.2.2
Athos concepts templates
The OPAL meta-model is used in the user interface of Athos to guide the Knowledge Engineer in
the construction of an Ontology. In OPAL, a concept is specified according to a traditional Frame-SlotFacet modeling paradigm. In particular, there is a frame structure (template) for each concept
category. OPAL templates are used in the interface of Athos to allow the user to introduce domain
concepts in the ontology.
To show its structure an example of “template for Business Concepts” is shown in Figure 1.
Figure 1.
Athos Template structure: a Business Object Document example
An Athos template is organised in three sections:
•
Identification Section;
•
Structural Section;
•
Specific Section.
The first two sections are the same for all the three templates, while the third section is designed
specifically for each template, with the aim to represent domain specific links and dependencies
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 206 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
2.2.3
507849
Identification Section
It contains an intuitive and textual description of the concept, plus a number of meta-information
fields:
•
Label: the preferred term to refer the conceptDescription: a natural language description
•
XMLTag: a tag that can be used to refer to the concept in a XML documentTerminology:
synonyms of the preferred termsAuthor: who defined the concept
•
References: documental sources used for the concept definition
2.2.4
Structural Section
It contains:
•
Attributes: they are classified as:
o Atomic Attributes: elementary data properties;
o Complex Attribute: structured data properties.
•
Hierarchies:
o ISA: concepts specialization (e.g., an invoice is a business_document)
o Part of: concepts decomposition (e.g., a department is part of an enterprise)
o Relatedness: domain specific relationship between concepts (e.g., the invoice is related to the
customer)Specific Section
While the first two sections are the same for each concept kind, the Specific Section is different
from one concept to another. Furthermore, while in the Structural Section the user is free to define all
the elements required to specify a concept, in the Specific Section the elements to be filled are
predefined and the user can not modify the given structure.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 207 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
The features of the Specific Section for each concept category (kind) are the following:
Object Specific Section
An Object has a Specific Section that reports the following information:
•
GeneratedBy, UpdatedBy, UsedBy, ArchivedBy: the Processes that create, manipulate, archive
the Object;
•
States, labelled boolean expressions over the Object attributes or those of related concepts
Process Specific Section
The relations that are part of the Specific Section of the Process template are:
•
Creates, Updates, Enquires and Archives Business Objects: the business objects that are directly
accessed or manipulated by the Process;
•
In, Out and Fault Messages: the incoming, outgoing messages of the Process. The Fault
messages: allow to model the exceptions handling;
•
Actors: the actors that are requested for the execution of the Process;
•
EstimatedTime: the estimation of the Process execution time.
Actor Specific Section
The relations that are specified in the Specific Section of the Actor are:
•
Goals, objectives that must be accomplished by the Actor, in the form of an OCL expression
(e.g., salaries should be less that 60% of deprtment budget)
•
Skills, indicating the actions it is able to perform or monitor (i.e., list of processes and/or
operations)
•
Responsibilities, the processes in which the Actor is involved, in achieving a Goal (as above),
with his/her/its respective role (i.e., performer, controller, stakeholder, supporter), and the Objects
he/she/it can manage;
•
Collaborations, the other actors involved in the performed activities.
Message Specific Section
A Message (M) is here considered as a particular case of Business Object. Assuming that, the
Message templates is a specialization of the Object template. It means that all the features of the
Object template are in the Message template, and at the same time in the Message template we have
some more characteristics.
The relations that are part of the Specific Section of the Message template are:
•
Source, the Actors who send the message;
•
Destination, the Actors who receive the message;
•
Content, the Business Object Document that is carried by the Message;
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 208 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
•
507849
PrecedingMessages, the set of Messages that can precede a given Message in the iteraction
between two Processes
•
FollowingMessages, the set of Messages that can precede a given Message
•
PreCondition, a boolean expression that must be true in order to allow the sending of the
Message.
Business Object Document Specific Section
Like the Message template, also the Business Object Document (BOD) template is here
considered as a particular case of Business Object and then considered as a specialization of the
Object template.
The relations that are specifically part of the Specific Section of the BOD template are:
•
AuthoredBy, the Actors who can be identified as the authors of the BOD;
•
CarriedBy, the Messages that can carry the BOD as their actual content.
Atomic Attribute Specific Section
The features of the Specific Section of the Atomic Attribute template are:
Domain, the set of concepts for which a predication with the Attribute can be established. Please,
note that, if this property is valued with a list of concepts, the domain must be interpreted as the union
of the set of instances of the specified concepts;
•
Range, the basic type of the attribute. Possible values are: ‘int’, ‘real’, ‘string’;
•
Functional, boolean value that says if for each instance of the Domain there is at most one
instance of the Attribute (if more than one, then they represent the same object);
•
InverseFunctional, boolean value that says if for each instance of the Range there is at most one
instance of the Domain.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 209 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Complex Attribute Specific Section
The features of the Specific Section of the Complex Attribute template are:
•
Domain, the set of concepts for which a predication with the Attribute can be established;
•
Functional, boolean value that says if for each instance of the Domain there is at most one
instance of the Attribute (if more than one they represent the same);
•
InverseFunctional, boolean value that says if for each instance of the Range there is at most one
instance of the Domain.
2.3
Athos concepts references and use
2.3.1
Concepts list
The process of ontology generation requires an initial definition of the ontology domain
vocabulary; this process is performed in Athos with the identification of the ontology concepts into a
“concepts list”, that contains two basic definitions:
•
Label: a term that denotes the concept (mandatory);
•
Kind: the category to which the concept belongs.
The couple formed by the label and the kind of any concept must be unique (mandatory).
2.3.2
Pending list
The listed concepts are “fixed” or “pending” with reference to the process that has created them.
In addition to the terms referring to concepts specified in the ontology there are some terms named
Pending terms. During its definition, a concept can be associated through any of the above relations,
to concepts not yet defined. Such concepts will be referred as Pending terms.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 210 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
3
507849
The Athos System
The Athos software system has been developed by LEKS, IASI-CNR within the Athena Project,
to support the definition and management of domain ontologies. Its main characteristics are described
in the following paragraphs.
3.1
Generality
The creation of an ontology in Athos is performed by filling forms organised in accordance with
the OPAL meta-model briefly. The system is accessible via a web browser (in the first version only
through Internet Explorer). All the ontology functions, such as concept specification and updating,
concept reading, system management, an, and administration, can be performed remotely.
The Athos system server, with the ontology repository, is centrally managed by an
“Administration Team”, dedicated to accomplish all the activities for the Athos system maintenance
and use.
3.2
Athos User categories
Athos is an ontology management system capable of managing several ontologies. The access to
an ontology is regulated defining groups and users, with different access privileges.
In order to have a controlled access to each defined ontology, the “Athos Administration Team”
grants the access to each ontology, through appropriate procedures (see also
the “Athos
Administration Service” and the “Accept ties” to use the system).
The Athos Administrator manages, in agreement with the responsible of the ontology (the
Ontology Master, see below):
•
access authorizations: on request assigning a user ID and a password;
•
different access levels: two access rights levels have been identified, that correspond to the
following user’s profiles:
o Ontology User;
o Ontology Master;
•
organisation of users in groups (User Groups);
•
access restriction through the use of passwords;
•
access monitoring through a log file.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 211 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
An additional profile, as previously said, is represented by the Athos Administrator, who may
create new accounts, remove or modify existing accounts and defines the types of access rights to be
granted to a specific user. To perform these activities the Athos Administrator works in conjunction
with the User’s Organizations. In particular with the Ontology Master for the domain of interest of
the ontology, in order to check and endorse the user and group organization.
3.3
Ontology users and group organisation
Ontology Users and Ontology Masters are organised into User Groups, each of which is
associated with the set of ontologies they can access. The privileges of the Ontology Users are
restricted to the browsing of ontologies, while the Ontology Masters can use all the facilities that
Athos supplies.
The Ontology Masters are the responsible of the management of an ontology.
Each user may belong to different User Groups and logs in an ontology by using a user ID and a
personal password. All the access rights of the Ontology User are extended to the Ontology Master.
In particular:
•
the Ontology User can access and browse the ontology, but cannot modify its content;
•
the Ontology Master has the possibility of using all Athos facilities to create concepts or to
modify existing concepts.
In this user guide, the user access rights will be described incrementally, starting from the level
granted to an Ontology User, to the access level granted to an Ontology Master.
3.4
Athos Login
The Athos system is accessible via the Internet at the address http://leks-pub.iasi.cnr.it/Athos.
After connection with the Athos home-page, the Athos Login window appears (Figure 2),
allowing the user to access to Athos by filling:
•
the User Name field: with the user ID assigned by the Administrator;
•
the Password field: the related password assigned by the Administrator.
.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 212 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 2.
507849
Login window
(Format and Language into the window is browser dependent).
The OK button allows the user to submit the inserted data and, if correctly identified, to enter.
If user name or password are wrong, the following Unidentified user message appears:
“You are not authorized to access this resource”
The Athos users are organised into User Groups, each of which has access to predefined
ontologies. Each user can only access the ontologies created within the User Groups he/she belongs
to. The same ontology can be made available to different User Groups. Furthermore, the same user
can access different ontologies with the same or a different user access rights.
The system opens the Ontology Login page shown in the Figure 3 with one or more
environments, identified as user access rights. According to the combination of the selected User
Group and the specific ontology, the system is able to recognise the access level (the category) of the
user.
Depending on the user category, Athos allows the access to different ontology environments.
A click on the ontology name allows the user to reach the desired Ontology environment
required.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 213 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 3.
3.5
507849
Login page
Athos Logout
In order to disconnect (log out) a user from a given ontology, a user has just to close the browser
window.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 214 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
4
507849
The Athos Interface description
When a user connects to a specific ontology, the system opens a working environment. Athos has
two main environments corresponding to the two user categories introduced in the previous section:
•
Ontology User,
•
Ontology Master.
They differ among them for the enabled functionalities.
As anticipated, the Ontology Master environment enables all the Ontology User environment
functionalities and some additional ones. For this reason the user interfaces of the different
environments will be presented incrementally, starting from the first screen that appears after login, as
shown in Figure 4.
Figure 4.
4.1
The Athos standard interface - Menu bar
The Menu Bar
The Menu Bar is indicated in Fig.4; it is composed of three buttons; (each element is active only if
the user has the enabled functionalities to use it) The three buttons are:
•
Main: activates the operations that the user can perform on the ontology:
•
Modes: defines the basic modalities in which it is possible to use the tool; they are:
•
Glossary Mode;
•
Ontology mode:
•
Help: that allows the user to access to the Athos guide
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 215 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
4.2
507849
The Navigation Bar
The Navigation Bar is highlighted in Figure 5
Figure 5.
FigureThe Athos standard interface - Navigation bar
The Navigation Bar is indicated in Fig. 5; it is composed by four buttons that activate the display of
different panels related to the functions:
•
List: activates the list panel of the ontology concepts;
•
Specialisations: activates the specialisation functional panel;
•
Decompositions: activates the decomposition functional panel;
•
Search: activates the search functional panel.
A detailed description of the above functions is provided in the following paragraphs.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 216 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
4.3
507849
The Concept List panel
The concept list panel is highlighted in Figure 6
Figure 6.
The Athos standard interface – Concept List
The Concept List panel shows the list of all the concepts of the selected ontology, in alphabetic
order. Each concept is represented by its Label and Kind. In addition each item has a green/red
indicator that show the concept status (fully defined concepts = green or pending terms = red).
Beside the Concept List, the concepts can be also shown according to the following views:
•
Specializations: activated through the Specialisations button on the navigation bar allows
concepts to be organized according to a specialisation hierarchy;
•
Decompositions: activated through the Decompositions button on the navigation bar This button
allows concepts to be presented organized according to a decomposition hierarchy.
The function associated to the Search button are described later in chapter 5.4.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 217 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
4.4
507849
The Identification Section panel
The Identification Section panel is highlighted in Figure 7
Figure 7.
The Athos standard interface – Identification Section
The Identification Section displays the meta-data of the concept selected from the concept list.
Two buttons Edit Concept and Delete Concept, located at the bottom of the Structural panel,
allow the user ( these options are reserved to the Ontology Master) to perform Edit or Delete
operations on a concept, selected in the list. Additional details of this functions are described later into
the Master environment section (Section 6).
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 218 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
4.5
507849
The Structural Section panel
The Structural Section panel is highlighted in Figure 8
Figure 8.
The Athos standard interface – Structural/Specific Section
Below the Identification Section panel, the Structural Section button and the Specific Section
button, allow to show, in an additional panel, respectively the Structural Section and the Specific
Section.
Additional details about the content of the Structural Section are given in Chapter 4
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 219 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
5
507849
Ontology User Functions
When an Ontology User enters in the Ontology User environment, the Menu bar functions are
activated, the Navigation bar functions are activated and the List panel shows the Concepts of the
accessed ontology (in Label alphabetical order). The panels regarding the Identification Section, the
Structural Section and the Specific Section are empty (see Figure 9).
Figure 9.
The Ontology User Environment – Default display
As already mentioned, the Ontology User environment allows the Ontology User to inspect the
ontology. The user, through the List function can:
•
select the modality of list display (by double clicking on the Label or Kind button);
•
scroll the concepts list
•
select a concept (by clicking with the left button on the mouse); the concept line will be
highlighted;
•
View the corresponding concept details through the Identification Section, Structural and Specific
Section
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 220 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
5.1
507849
Display a concept
To display a concept of the ontology, a User has to select a concept from the Concept List, in the
left section, with a click on the row.
Figure 10.
Display a concept: Identification Section
In the Figure 10 the concept Address has been selected. These operations display the content of
the concept in the panels on the right.
5.1.1
The Identification Section
The Identification Section panel shows the main information about the selected concept, that are:
Label, Kind, Description, XML Tag, Terminology and References
as described into the introduction section of this manual.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 221 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
5.1.2
507849
The Structural Section
The Structural Section panel is highlighted in Figure 11.
Figure 11.
Display a concept: Structural Section
The Structural Section of the selected concept is presented according to a tree structure that can
be expanded, similarly to a Windows folder tree.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 222 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
5.1.3
507849
The Specific Section
The Specific Section panel is highlighted in Figure 12.
Figure 12.
Display a concept: Specific Section
The Specific Section of the selected concept is also presented according to a tree structure that
can be expanded, similarly to a Windows folder tree.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 223 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
5.2
507849
Display a concept specialisation hierarchies
To display a concept specialisation hierarchy of the ontology, a User has to click on the
Specialisations button of the Navigation menu bar. The user selects a concept from the
specialisation hierarchy, by clicking on the row with the left button of the mouse. The concept details
are displayed in the Identification Section (Figure 13).
Figure 13.
Display the specialisation hierarchy
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 224 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
5.3
507849
Display a concept decomposition hierarchies
To display a concept decomposition hierarchy of the ontology, a User has to click on the
Decompositions button of the Navigation menu bar. The user selects a concept from the
decomposition hierarchy, by clicking on the row with the left button of the mouse. The concept details
are displayed in the Identification Section (Figure 14).
Figure 14.
Display the decomposition hierarchy
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 225 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
5.4
507849
The search function
5.4.1
The search function activation
In order to search concept(s) in the Ontology, a user has to click on the Search button of the
Navigation bar; this action activates the Search panel (Figure 15).
Figure 15.
The Search function
The Search panel shows two fields:
•
the Search by field: this is a pull-down menu that defines the concept search criteria; in this first
version the criteria you can apply are searching by: Label, Kind, Description and XMLTag;
•
the Value field: is used to insert the search expression; it can be specified as a regular
expression;
The Value field accepts a value freely specified by the user. The Search button activates the
process.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 226 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
The output of the search operation is shown in a list displayed below the search button (Figure
16).
Figure 16.
The Search Result
If more than one concept is found , the selection of one displays its details in the Identification
Section panel at the right of the screen.
5.5
The glossary mode function
5.5.1
Glossary mode
The normal Athos modality of operation is in Ontology Mode; The Modes button on the Main
Menu bar allows the User to operate in Glossary Mode, by selecting the option Glossary Mode into
the banner (see Figure 17).
When this operation mode is activated the Identification Section panel is expanded to allow the
full display of all information related to the concept that can be selected by a mouse click on the
concept list panel.
This mode of operation is particularly useful when new concepts for a specific reference
ontology are collected and evaluated.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 227 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 17.
5.5.2
507849
The Glossary display
Export glossary function
In the Athos system User has the option to export a Glossary from the Concepts List. This option
is related to the list in the left section; to this end he/she has to click on the Menu bar the Main button,
selecting the option Export Glossary into the banner (Figure 18).
Figure 18.
Export Glossary function
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 228 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
The result is a Glossary page organized as follows, like a print page form (Fehler! Verweisquelle
konnte nicht gefunden werden.). Please note that each concept may have more than one
Description. The Kind of a concept is reported in square brackets.
Figure 19.
5.6
Glossary List
Print a concept
Athos system provides the option to save, copy or print a concept, offering to the users to do
these actions via the browser options.
To print a concept, for example, a user must:
select a concept from the Concepts List;
chose the Identification Section sub-area (via mouse) he/she like to print,
•
click the right side button on the mouse to open the browser menu with the options,
•
chose Print option and activate it.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 229 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
6
507849
The Ontology Master Functions
The Ontology Master, with respect to the Ontology User, is also enabled to modify the ontology
content. Similarly to the Ontology User environment, the Ontology Master environment allows to
View or Search concepts.
In addition the Ontology Master environment allows an Ontology Manager to:
•
Create a new Concept;
•
Edit an existing concept;
•
Delete an existing concept.
In the Ontology Master environment the Main button offers the New Concept option (see
Figure 20).
The Edit Concept and the Delete Concept buttons are enabled to enabling editing and deleting
operations on concepts.
Figure 20.
The Ontology Master environment
Since the View and Search functions are the same as in the Ontology User environment, in the
following sections, only the additional functions will be described. To see how to View or Search a
concept, see the Chapter 5 - The Ontology User environment of this manual.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 230 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
6.1
507849
Create a new concept
To create a new concept, an Ontology Master has to click on the Main button in the Menu bar
and choose to click the New Concept tab. This operation opens the Identification Section Form in a
popup window (Fig 21 – upper and lower working area). The window has:
•
on the top: a menu bar with the buttons Identification Section, Structural Section, Specific
Section to select one or another of the three available sections required to completely define a
new concept (Identification, Structural, Specific).
•
inside the window, depending on the selected buttons on the top, one of the three different
forms, corresponding to one of the concept sections, with fields and buttons to correctly insert the
requested information. By default the form related to the Identification Section is initially
displayed.
6.1.1
Input of the Identification Section
Starting from the Identification Section, that is normally the first one to be filled, we see the fields
(with self-explanatory labels) that represent the required information for the Identification Section of a
concept (see the Introduction - Athos concepts organization).
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 231 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 21.
Creation of a new concept -
Figure 22.
The Identification Section
507849
Creation of a new concept The
Identification
Section
(cont’d)
The Kind, Label and Description fields are three mandatory fields for the definition of a concept.
Clicking on the “Kind” (Figure 21) field, a pull down menu with the concept kinds proposed by the
OPAL methodology is displayed. By selecting a row the Ontology Master can choose a specific kind
for the New Concept he/she is going to create.
After the kind selection, the Ontology Master has to fill, with appropriate data, the fields Label and
Description, (Required fields), while the other fields, Author, XML Tag, Terminology and
Reference, can be omitted. All fields, during the creation cycle, can be rewritten to change the
content, before saving the new concept.
The fields in which the Ontology Master may insert more than one statement (Terminology and
Reference – Figure 22), accept (and show just under the insert area) more than an input; each
additional input can be inserted via the Add button. Each statement into these two windows may be
removed, by selecting it with a click on the row and then clicking the Remove button.
At the end of the data insertion on this panel the Master may:
click on the Save Concept button (Fehler! Verweisquelle konnte nicht gefunden werden.) to
save the new concept containing only the inserted definitions already built on ;
click on the Reset button to reset all the work done;
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 232 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
click on one of the Top bar buttons, to select another pop-up window (either Structural Section or
Specific Section) to add other inputs to the new concept.
6.1.2
Input of the Structural Section
The Structural Section, (normally the second one that the Ontology Master fills), is activated as
a pop-up panel into the same window panel in which the Identification Section was displayed; the
panel contains buttons and fields to insert the data required to fill the Structural template of the new
concept. (Figure 23 for upper and Figure 24 for lower area).
Figure 23.
Creation of a new concept -
Figure 24.
Creation of a new concept The Structural Section(cont’d)
The Structural Section
Each field (with self-explaining identification labels and target buttons) may be used to define the
information linked to the new concept (see the Introduction - Athos concepts organization). In
particular it is possible to Add (but also to edit or remove, because the same panel is used for edit and
remove functions, as later explained) Attributes, Hierarchies, Relatedness.
Depending on the kind of concept to be specified, the interface presents different windows to be
filled.
In Figure 25 and Figure 26 the attributes of a new Business Actor are inserted. Opening the
corresponding Structural Section, the Attributes window will be active. Clicking the Add button (Figure
25 – Structural Section), a popup sub- panel will be opened (Figure 26).
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 233 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 25.
Creation of a new concept -
Figure 26.
507849
Creation of a new concept Attribute addition (cont’d)
Attribute addition
In the popup sub-panel it is possible to enter a new concept (if it is not yet defined, this concept is
considered as a Pending concept and becomes part of the Pending list), or to select an existing
concept from the concept list, and link it to the new concept. Such a concept must be, in this case, an
Atomic Attributes [AA] (or elementary data property) or Complex Attribute [CA] (structured data
properties) that are the only two kind of concepts linkable like “attribute” to a new Business Object. As
will be shown later with an example, the action performed on this panel will generate information, to be
written into the “Attributes window”.
The same process is available for all the other data that is possible to manage via this panel. At
the end of the data insertion on this panel the Ontology Master may:
•
click on the Save Concept button
to save the new concept containing only the inserted
definitions already built on (in case of a future editing to add further information);
•
click on the Reset button to reset all the work done;
•
click on one of the Top bar buttons, to select another pop-up window (either Identification or
Specific) to add other inputs to the new concept.
6.1.3
Input of the Specific Section
The Specific Section, that is normally the third one the Master fills, appears into the same popup
panel in which the Identification and Structural Section were and show buttons and fields to insert the
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 234 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
data to compose the Structural tree of the new concept (Figure 27 for up and Figure 28 for down
area).
Figure 27.
Creation of a new concept -
Figure 28.
Specific Section
Creation of a new concept Specific Section (cont’d)
Each field (with self-explaining identification labels of identification and target buttons) may be
used to define the information linked to the new concept (see the Introduction - Athos concepts
organization).
In particular it is possible to Add (but also to edit or remove, because the same panel is used for
these functions, as later explained) specific information concerning how the concept is used in the
modelled scenario. As for the Structural Section, depending on the kind of concepts to be specified,
the interface presents different fields to be filled. For instance, the user should fill the fields
GeneratedBy, UpdatedBy or States, for Object, and Goals, Skills, Responsibilities, Managed Objects,
Collaboration for Actor.
The process of filling the Specific Section is very similar to the one described for the Structural
Section (see Fig. 23 -right). At the end of the data insertion on this panel the Ontology Master may:
•
click on the Save Concept button
to save the new concept containing only the inserted
definitions already built on (in case of a future editing to add further information);
•
click on the Reset button to reset all the work done;
•
click on one of the Top bar buttons, to select another pop-up window (either Identification or
Structural) to add other inputs to the new concept.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 235 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
6.2
507849
Example of creation of a new concept
To better clarify the new concept creation process through the Athos system a short example
follows.
The Ontology Master decides to add to the ontology the new concept Delivery-Doc as a
BusinessOb ject. First of all he/she has to select on the New concept row on the Main Button banner
of the Menu Bar and open the “Identification Section” window (Figure 29 and Figure 30). Since
Delivery-Doc is a “BusinessObject”-kind concept , the Ontology Master has to select
“BusinessObject” from the Kind choice menu. Then using the panel facilities, he/she has to fill at least
the “Label” and “Description” text fields as shown in the Figure 29.
Figure 29.
Creation of a new concept-
Figure 30.
Creation of a new conceptIdentification example (cont’d)
Identification example
Once all the data have been checked, he/she moves to the Structural Section selecting the
corresponding button on the top bar (remember that he/she may also decide to click on the Save
Concept, saving only the Identification Section information, or to clear all by clicking on the Reset
button).
Moving to the Structural Section a different panel is shown. In this window (Figure 31) he/she may
add an Attribute to the concept by selecting an existing one from the ontology list (in this activity only
the Atomic or Complex Attribute Kind concepts are displayed) or by defining a new label. In the latter
case a Pending term is created. The concept is Pending until its definition will be completed.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 236 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
In both alternatives, the Athos system supports user by opening a popup sub-panel (Figure 32).
Figure 31.
Creation of a new concept-
Figure 32.
Structural example
Pop-up
window
for
the
definition of a property
In the example the Ontology Master adds an attribute by selecting (Fig. 26 – left) the Complex
Attribute “Address” from the ontology list. Then the system opens another popup window (Fig.26 –
right) where the Ontology Master can define the cardinality values and save the attribute.
The defined attribute can be shown in the Attribute window in the Structural Section panel, (Figure
33).
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 237 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 33.
507849
Creation of a new concept- Example of an Addition of an attribute
The process of defining Attributes is very similar to the process of correlating two concepts with
relationships (e.g. ISA, Part-of, Relatedness).
In this example the Specific Section is not filled since this process is very similar to those
described for the Identification Section and Structural Section.
Finally the Ontology Master saves the work done by clicking the Save Concept button. The
system confirms this with a popup window that displays “Your changes have been saved”, prompting
him/her to terminate the operation with the Close button.
The concept created is added in the Concept list. Figure 34 shows both the concept list and the
Identification Section as displayed when Athos System is in the glossary mode.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 238 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 34.
6.3
507849
Creation of a new concept- Display of the inserted concept
Editing an existing concept
To edit an existing concept, an Ontology Master has to select a concept from the Concepts list
panel and then click on the Edit Concept button in the right panel (see Fig.28 above).
Once the Edit Concept button has been clicked the Identification Section popup window is
opened (Figure 35 and Figure 36)
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 239 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 35.
Editing an existing concept
Figure 36.
Editing an existing concept
507849
(cont’d)
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 240 / 244
IP- Project
ATHENA
IP- Project - No
507849
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
All the values of the different fields are displayed in the Identification Section . The panel allows
the user to modify Label, Descriptions, Author, XMLTag, Terminology, References, whereas the Kind
field is fixed.
Selecting the Structural Section label the system opens a different window in the same panel. In
this window (see Fig 22) he/she may decide to change or add something to the concept, picking up
existing concepts from the ontology list; this list displays only the concepts with the appropriate Kind,
according to the OPAL constraints). The Ontology Master can also define new labels and,
consequently, “pending terms”. As previously said, a term is “pending” until it will be defined as a
concept.
Successively, selecting the Specific Section (as already described - see Figure 27and Figure 28)
the Ontology Master can modify the value of all the fields , with a process similar to that shown for the
Structural Section via popup windows and data ties.
Finally, he can save (change) the edited concept by clicking on the Save Concept button. The
system confirms the modifications with a pop-up window that displays “Your changes have been
saved”, prompting him/her to terminate the operation with the Close button.. Otherwise he/she may
cancel the modifications by clicking the Reset button.
6.4
Deleting an existing concept
To remove a concept from the ontology, the Ontology Master has to select it from the Concept
list and then click on the Delete Concept button in the right section.
Once the Delete Concept button has been activated, Athos prompts him/her to confirm the
activity, by showing the Delete confirm window (Figure 37).
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 241 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
Figure 37.
507849
Deletion of an existing concept
If the Ontology Master selects the OK button, the concept will deleted from the ontology, and all
the relations with the other concepts are removed. Otherwise, if the user selects the No button, the
concept will not be deleted from the ontology.
6.5
Pending terms management
As previously clarified into this manual, in addition to the terms referring to concepts specified in
the ontology, some terms, related to concepts not yet defined, are named Pending terms.
These pending terms are created during the definition process of new concepts to be added to the
ontology and they are identified through any of the relations, built to connect to concepts not yet
defined. These references are considered Pending terms, are automatically tagged Pending. They are
included into the Concept List but are marked with a Red dot.. To transform a Pending term into a
concept, a Master has to Edit the term like a Concept and supply all the appropriate information,
following the edit procedure.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 242 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
7
507849
INDEX
Actor; 9; 10; 13; 43; 45
Atomic Attribute; 14
Business Object Document; 10; 11; 13; 14
Complex Attribute; 10; 12; 14; 43; 49
concept; 4; 9; 10; 11; 12; 15; 16; 23; 24; 26; 27; 28; 29; 30; 31; 32; 33; 34; 35; 36; 37; 38;
39; 40; 41; 42; 43; 44; 45; 46; 47; 49; 50; 51; 52; 53; 54; 55
Concept; 3; 23; 24; 26; 37; 39; 40; 41; 44; 46; 48; 50; 51; 52; 54; 55
conceptualisation; 9
Identification Section; 3; 4; 11; 24; 25; 27; 30; 31; 33; 34; 36; 39; 40; 42; 47; 48; 50; 51; 52
kind; 12; 15; 40; 42; 43; 45; 47
Knowledge Engineer; 10
Message; 10; 13; 14
metamodel; 3; 9
Object; 9; 10; 11; 12; 13; 14; 43; 45
Ontology; 3; 4; 8; 9; 10; 16; 17; 18; 19; 20; 21; 24; 26; 32; 34; 37; 39; 40; 42; 44; 46; 47; 49;
50; 52; 54; 57
ontology management system; 16
Ontology Master; 8; 17; 37; 47; 49
Ontology User; 20; 26; 37; 38
Process; 9; 10; 12; 13
Specific Section; 3; 4; 11; 12; 13; 14; 25; 26; 29; 39; 41; 45; 46; 50; 53
Structural Section; 3; 4; 11; 12; 25; 26; 28; 39; 41; 42; 43; 45; 46; 47; 49; 50; 52; 53
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 243 / 244
IP- Project
ATHENA
IP- Project - No
ATHENA - Project:
Knowledge Support and Semantic Mediation solutions
ATHENA - Project No
A3
Document
Deliverable DA.3.1- part C
Date
2005
8
[1]
507849
References
“IDEF5
Ontology
Description
Capture
Method
Overview”;
http://www.idef.com/overviews/idef5.htm.
[2]
M. Uschold, M. Gruninger; “Ontologies: Principles, Methods and Applications”;
The Knowledge Engineering Review, V.11, N.2, 1996.
D.A3.1- Part 3 - Athos Manual V1.0
CONFIDENTIAL
Page 244 / 244
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement