050404 athena da31 summary v10 - ap242 provided to e… · athen a - project no a3 deliverable...

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 IP- Project - No 507849 ATHENA Project Knowledge Support and Semantic Mediation Solutions ATHENA - Project Number Document Deliverable A3.1 Date 04.04.05

050404_ATHENA_DA31_Summary_v10.doc CONFIDENTIAL Page ii / 244

Deliverable process schedule No Process step Responsible Timing Comments

1

Initial drafting of the deliverable including structure, comments and first basic content to be sent to to-be-contributors.

F. Taglino (CNR) M.Missikoff (CNR) 05.07.2004

2

First round of contributions. Work package member and others to contribute first iteration to owner of the deliverable

F.Taglino (CNR) D. Gazzotti (Formula) S-M Thomas (SAP)

27.08.2004

3 Owner to consolidate first round input and distribute to contributors F. Taglino (CNR) 22.10.2004

4 Final round of contributions including comments form peers/AL to be sent to owner

F.Taglino (CNR) L. Pondrelli (Formula) S-M Thomas (SAP) E. Coscia (TXT) F.W. Jaekel (IPK)

14.01.2005

5 Final consolidation of input and finalisation of “technical” document to be send to

F. Taglino (CNR) M. Missikoff (CNR) G. Callegari (CNR)

28.01.2005

6 Quality check – e.g. Peer Review Elmar Dorner (SAP) 14.03.2005 Only part B has been revised. We didn’t receive any feedback for Part A and B.

7 Final editing Programme office 26.07.2005

8 Final Approval from partners or delegates to be send to Programme Office

PCC members or delegates: Guy Dougmeings (itrec) Joerg Muller (Siemens)

21.03.2005 31.03.2005

9 Submission to Commission Programme Office 04.04.2005


050404_ATHENA_DA31_Summary_v10.doc CONFIDENTIAL Page iii / 244

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 3.1.1 Ontology modelling languages 3 3.1.2 Ontology related software systems 4 3.1.3 Ontology content 6 3.1.4 Relationship between the Interop and the Athena SoA 7 3.2 DA3.1-B Summary. Athos technical Specifications 7 3.2.1 The representational specifications of Athos 7 3.2.2 The functional and architectural specifications 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 1 / 244

1 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.



2 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.



3 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.



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.



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



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



• 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.



3.2.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: 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.



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.


Strategic Objective



Acronym

ATHENA Project No



A3



Modelling Language. Part A: State of the Art on Ontologies



March 31st, 2005

Version 1.1

IP- Project ATHENA IP- Project - No 507849 ATHENA -Project Programme ATHENA - Project Number Document Deliverable A3.1 Part A Date 04.04.05

050404_ATHENA_DA31_PartA_V10.doc/derek CONFIDENTIAL Page 11 / 244

Versioning and contribution history Version Description Comments

0.1 First draft – Contribution from LEKS, FORMULA an SAP 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 Process step Responsible Timing Comments

1



2



27.08.2004




14.01.2005



28.01.2005





21.03.2005 31.03.2005

9 Submission to Commission Programme Committee



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 23 2.3.1 Conceptual graphs 24 2.3.2 Semantic networks 24 2.3.3 UML (Unified Modeling Language) (detailed form) 25 2.3.4 Topic Maps 26 2.3.5 Concept Maps 27 2.4 Logic-oriented 27 2.4.1 KIF (Knowledge Interchange Format) 28 2.4.2 Cycl 28 2.4.3 SCL (Simple Common Logic - CL working group) 29 2.4.4 LP/Prolog 29 2.4.5 SWRL 30 2.4.6 F-Logic (M. Kifer, G. Lausen, J. Wu) 30 2.4.7 Description Logics (a family of languages) 31 2.5 Frames-oriented 32 2.5.1 Frame Systems 33 2.5.2 OKBC 33 2.5.3 XOL 34 2.5.4 SHOE 34 2.5.5 Ontolingua 35 2.5.6 OCML 36 2.5.7 OIL (Ontology Inference Layer) 37 2.6 Web-oriented 37 2.6.1 XML Schema (W3C consortium) 37 2.6.2 DAML+OIL 38 2.6.3 RDF(S) 38 2.6.4 OWL (Ontology Web Language) scheda 39 2.7 Process specification languages 40 2.7.1 Process algebras 41 2.7.2 Pi-Calculus 41 2.7.3 PSL (Process Specification Language) 41 2.7.4 Petri Nets 45 2.7.5 OWLS-S 45 2.7.6 BPEL 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



3.3.1 KAON 84 3.3.2 Ontolingua (with Chimaera) 84 3.3.3 OilEd 85 3.3.4 Protégé 2000 86 3.3.5 pOWL 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 96 5.1.1 IBM Integrated Ontology Development Toolkit 96 5.1.2 IBM Ontology Management System (SNOBASE) 96 5.1.3 IBM Ontology-based Web Services for Business Integration 97 5.2 KPONTOLOGY 97

6 EAI solutions (Enterprise Application Integration) 98 6.1 EAI in the semantic context 98 6.2 EAI solutions 99 6.2.1 IBM - Web Sphere Business Integration [25] 99 6.2.2 Microsoft – BizTalk [26] 99 6.2.3 TIBCO – ActiveEnterprise [29] 100 webMethods - Integration Platform 101 6.2.4 SeeBeyond – Integrated Composite Application Network (iCAN) [28] 101 6.2.5 BEA WebLogic [30] 102 6.2.6 SAP Netweaver [35] 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 115 7.3.1 Overview of GEFEG – copied from their web site: 116 7.4 ISO Standards as a source of terminology 116 7.4.1 ISO Standards related to terminology management 117 7.4.2 Short Description of ISO 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 121 7.10.1 Explanation of Core Components 122 7.10.2 Core Component Types 123



7.10.3 Business Information Entities 123 7.10.4 Summary table for CCTS 124 7.11 Context 124 7.11.1 Processes associated with core components 126 7.12 MIT Process Handbook 126 7.13 SCOR 127 7.13.1 SCOR – source of information 127 7.13.2 SCOR summary 127 7.13.3 Overview of SCOR 128 7.13.4 SCOR and collaboration 130 7.13.5 SCOR Level 1 130 7.13.6 SCOR Level 2 130 7.13.7 SCOR Level 3 132 7.13.8 List of SCOR Process Elements from SCOR 5.0 (Level 3) 133 7.13.9 SCOR Project 133 7.13.10 Metrics 134 7.13.11 Tools 134 7.13.12 Relation to other vocabularies 134 7.13.13 Potential significance of SCOR for Athena 134 7.13.14 Other second-generation reference-models 135 7.14 Conclusions 135 7.15 References 135



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 CONFIDENTIAL Page 16 / 244

1 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 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.,




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



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



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



1.5 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



Section I Ontology methods and languages



2 Ontology methods and languages

2.1 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 ontology-based 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.

Five categories of specification languages have been identified. They are: 1) Diagrammatic notations 2) Logic-oriented 3) Frames-oriented 4) Web-oriented 5) 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].



LANGUAGES GRID

Diagrammatic notations

Logic-oriented

Frames-oriented

Web-oriented Process specification-

oriented Conceptual graphs

x x

Semantic networks

x

UML x x Topic Maps x x Concept Maps x KIF x CycL x Prolog x SWRL x F-Logic x x Non-Mon, modalities, temporal logics

Description Logics

x

Frame Systems

x

OKBC x XOL x x SHOE x OIL x Ontolingua x OCML XML Schema x RDF(S) x x x DAML+OIL x x x OWL x x PIF x PSL x Process Algebras

x

Pi Calculus, x ADT (B Calculus)

x

OWL-S x x WSMF x Petri Nets x x BPEL x x

Table 1. Languages categorization

2.3 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)



• Topic Maps • Concept Maps

2.3.1 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 NP-complete 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



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



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.

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

Conceptual Topic Relation

Conceptual Occurrence

Relation

Conceptual Association Relation

Conceptual Resource Relation



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 non-commercial 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).



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 meta-knowledge. 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



first order logic, with constructs to handle equality, default reasoning, skolemization, and some second-order 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 non-atomic 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



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 object-oriented 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.



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.



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).



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



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.



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.



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



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 (Frame-based systems, Description Logics and Web standards) to provide a general purpose markup-language 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.



2.6.2 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 (n-ary) 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



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



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,



• 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 net-based 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



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.



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.



Figure 2. 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.



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.



• 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 service-specific 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. The top level of the Service ontology

2.7.6 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



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 Predefined categories: To enhance the guidance in the ontology building 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

AND: Intersection OR : Union (Disjoint OR: union of disjoint concepts) NOT: Complement Enumeration: List of the instances

Restriction: Constraint over one or more properties of the concept Documentation: Natural language description and other metadata indicating the

author, the date of creation of the concept, the documental sources for the definition of the concept

Attributes Instance attribute: Attributes whose value may be different for each instance of the

concept. Concept attribute: Attributes whose value must be the same for all instances of the

concept. Polymorphic: Attributes with the same name and different characteristics for

different concepts Default slot value: To assign a value to the attribute in case there is no explicit value

defined for it. Type: To specify and constrain the type of the attribute (basic type) Cardinality: To specify and constrain the cardinality of the attribute Documentation: Natural language description and other metadata concerning the

attribute



Relations (Domain Relations) Relation name: The term used to refer the relation Cardinality: To specify and constrain the cardinality of the relation Domain: Indicate which is the domain concept for the attribute Range: Indicate the range in which the attribute assumes values Documentation: Natural language description and other metadata concerning the

relation Predefined Business Domain relations:

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: 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)

Equivalent: Assert that different descriptions represent the same concept (i.e., the concepts instances sets concide)

Similarity: Assert that the concepts represent similar entities Part Of: Assert that a concept represents a component of another concept

Disjoint: Assert that the concepts instances sets have no intersection Generic constraints expressed with First or higher order logic formulas:

The possibility of expressing axioms on concepts by using FOL (higher-OL) formulas

Properties of Attributes/Relations (Axioms on Attributes/Relations) Predefined Relations:

ISA: 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

Equivalent: Assert that different labels denote the same attribute Inverse*: Assert the existence of an inverse relation Reflexive*: Assert that (x,x) in R Symmetric*: Assert that if (x,y) in R then also (y,x) in R Transitive*: Assert that if (x,y) in R and (y,z) in R then also (x,z) in R Unique: Assert that the attribute can assume a unique value for each

object

Inverse unique: Assert that, for each attribute value can exist a unique object having that value for the attribute

Generic constraints expressed with First or higher order logic formulas:

The possibility of expressing axioms on attributes and relations by using FOL (higher-OL) formulas

Instances Multiple instantiation layers: The possibility of defining a meta-level, meta-meta-level, etc. Concept instance: The creation of instances of concepts Relations between instances:

The assertion of a relation between instances

Equivalent: Assert that different labels denote the same individual Comments This section will contain additional notes on the specific language.



Process Specific Section Control flow: Description of the ordering of execution of the processes

(e.g.,sequencing, fork, iterations) Message flow: Description of the interaction between two processes, in terms of

the exchanged messages State/transition 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

Activation/termination criteria

Description of the conditions for activation/termination of a process (e.g., pre and post-conditions).

Structural profile 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: 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.

Constructors: AND: Not Supported OR : Not Supported NOT: Not Supported Enumeration: Not Supported

Restriction: Not Supported Documentation: Not Supported



Attributes Instance attribute: 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.

Concept attribute: Topic characteristic; facet, facet value Polymorphic: No Default slot value: Not Supported Type: Facet type; facet value type Cardinality: Not Supported Documentation: Not Supported Relations (Domain Relations) Relation name: 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.

Cardinality: Not Supported Domain: Not Supported Range: Not Supported

Documentation: Not Supported Predefined Business Domain relations:

No


ISA: InstanceOf The new draft for the standard also considers explicitly the specification of a supertype-subtype relationship through an association having particular syntax.

Equivalent: Not Supported Similar: Not Supported Part Of: Not Supported

Disjoint: Not Supported Generic constraints expressed with First or higher order logic formulas:

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.




ISA: 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.

Equivalent: Not Supported Inverse*: Not Supported Reflexive*: Not Supported Symmetric*: All associations in topic maps are intrinsically symmetric as they

don’t have an orientation. However, association roles create an asymmetry.

Transitive*: Not supported Unique: Not supported

Inverse unique: 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: 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.

Concept instance: 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.

Relations between instances:

Association

Equivalent: Not Supported



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.


UML Concepts Predefined categories: Class Constructors:

AND: Only as multiple inheritance. OR : Not Supported NOT: Not Supported Enumeration: Enumeration

Restriction: Not Supported Documentation: Comment Attributes Instance attribute: Attributename:attributetype=defaultvlaue Concept attribute: Not Supported Polymorphic: Yes Default slot value: Specified as value for the attribute in the class specification Type: Specified as type for the attribute in the class specification Cardinality: Not Supported Documentation: Comment Relations (Domain Relations) Relation name: Association; AssociationClass

An association specifies a relationship between classes Cardinality: cardinality constraints on Association ends Domain: 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.

Range: See above Documentation: Comment Predefined Business Domain relations:

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



standard concept of relation as intended in most ontological languages.


ISA: Generalization Equivalent: Not Supported Similar: Not Supported Part Of: Decomposition/Aggregation

Disjoint: Disjoint (Applies to a set of subclasses of a class) Generic constraints expressed with First or higher order logic formulas:

OCL statements


ISA: Generalization of an Association Equivalent: Not Supported Inverse*: Not Supported Reflexive*: Not Supported Symmetric*: Not Supported Transitive*: Not Supported Unique: isUnique attribute of Association Ends

Inverse unique: isUnique attribute of Association Ends Generic constraints expressed with First or higher order logic formulas:

OCL statements

Instances Multiple instantiation layers: 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.

Concept instance: 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.

Equivalent: Not Supported



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: 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.

Constructors: AND: and OR : or NOT: not Enumeration: Not Supported

Restriction: Not Supported Documentation: Not supported Attributes Instance attribute: Not Supported Concept attribute: N/A Polymorphic: N/A Default slot value: N/A Type: N/A Cardinality: N/A Documentation: N/A Relations (Domain Relations) Relation name: Defrelation, deffunction Cardinality: 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…

Domain: Not Supported (ma sei sicuro??) Range: Not Supported (ma sei sicuro??) Documentation: Not supported Predefined Business Domain relations:

No, though KIF defines several relations that allow to talk about sets and lists of objects and about numbers.




ISA: Not Supported Equivalent: <=> Similar: Not supported Part Of: Not supported

Disjoint: Disjoint Generic constraints expressed with First or higher order logic formulas:

All KIF Axioms


ISA: Not supported Equivalent: <=> Reflexive*: Not supported Symmetric*: Not supported Transitive*: Not supported Inverse*: Inverse Unique: Not supported

Inverse unique: Not supported Generic constraints expressed with First or higher order logic formulas:

All KIF Axioms

Instances Multiple instantiation layers: In KIF it is possible to talk about KIF sentences using the quote

and the denotation keywords. Concept instance: ???? R(a), where R is a constant denoting a relation and a is

constant denoting an object. Relations between instances:

????? R(a), where R is a constant denoting a relation and a is constant denoting an object.

Equivalent: = Comments


F-Logic Concepts Predefined categories: Classname[ list of typed attributes and methods] Constructors:

AND: Logical AND ∧ OR : Logical OR ∨ NOT: Logical NOT ¬ Enumeration: Not supported

Restriction: Not Supported Documentation: Not supported



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: 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.

Polymorphic: Yes Default slot value: Not Supported Type: 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.

Cardinality: Allowed types are classes. Specifying (class1,class2) in a type definition means that the attribute belongs to both class1 and class2.

Documentation: Attributes may be scalar or set valued. No explicit restriction on cardinality.

Relations (Domain Relations) Relation name: Not Supported

F-logic does not support the concept of relation. Relations may be expressed using methods of classes.

Cardinality: N/A Domain: N/A Range: N/A Documentation: N/A Predefined Business Domain relations:

N/A


ISA: Class2::Class1 means that Class2 is a subclass of Class1. Equivalent: Not supported Similar: Not supported Part Of: Not supported

Disjoint: Not supported Generic constraints expressed with First or higher order logic formulas:

F-logic is a higher order logic. Axioms may be expressed in F-logic directly.




ISA: Not supported Equivalent: Not supported Reflexive*: N/A Symmetric*: N/A Transitive*: N/A Inverse*: N/A Unique: Not supported


See above

Instances Multiple instantiation layers: F-logic makes no distinction between instances, classes,

metaclasses etc. Concept instance: A :Class1 means that A is an instance of Class1 Relations between instances:

N/A

Equivalent: Not Supported Comments


ONTOLINGUA Concepts Predefined categories: Thing, Class, Define-class Constructors:

AND: and OR : or NOT: not Enumeration: one-of

Restriction: Not Supported Documentation: double quoted string inside a class definition. Attributes Instance attribute: :instance-slots, has-slot-value, has-slot-value-of-type, has-value Concept attribute: :class-slots Polymorphic: Not-supported

Apart from syntactic sugaring, Ontolingua defines slots as relations, and relation definitions are global.

Default slot value: :constraints, :default-slot-values Type: slot-value-type Cardinality: slot-cardinality Documentation: double-quoted string inside a class definition, Documentation Relations (Domain Relations) Relation name: define-relation Cardinality: ?? Domain: domain Range: range Documentation: Double-quoted string inside a relation definition, Documentation Predefined Business Domain relations:

Not Supported




ISA: (subclass-of C1 C2) Equivalent: <= =>, iff-def: Similar: Not supported Part Of: Class-partition, subclass-partition, exhaustive-subclass-partition

Disjoint: disjoint(?s1, ?s2) Generic constraints expressed with First or higher order logic formulas:

All KIF Axioms


ISA: (subrelation-of R1 R2) Equivalent: Alias Reflexive*: Reflexive-relation Symmetric*: Symmetric-relation Transitive*: Transitive-relation Inverse*: inverse(?r) Unique: One-to-one-relation

Inverse unique: Not Supported Generic constraints expressed with First or higher order logic formulas:

All KIF axioms

Instances Multiple instantiation layers: In KIF it is possible to talk about KIF sentences using the quote

operator. Concept instance: Within an instance definition : Define-instance instance-name

(Class-name) … In an axiom: (instance-of instance-name Class-name)


Not supported.

Equivalent: = 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 Frame-ontology. Where possible, we’ve also added the definitional lisp like form (one of define-class, define-relation,define-function, define-instance.




OIL Concepts Predefined categories: 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 slot-constraint actually imposes a subclass constraint on the class being defined with class-def.

Constructors: AND: AND OR : OR NOT: NOT Enumeration: one-of

Restriction: slot-constraint + has-value, value-type. Documentation: documentation Attributes Instance attribute: 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.

Concept attribute: 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.

Polymorphic: 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)

Default slot value: Not supported Type: Value-type, has-value Cardinality: Min-cardinality, max-cardinality, cardinality Documentation: Not supported



Relations (Domain Relations) Relation name: Slot-def Cardinality: 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: domain Range: range Documentation: Documentation Predefined Business Domain relations:

Not Supported


ISA: subclass-of Equivalent: equivalent Similar: Not supported Part Of: Not supported

Disjoint: Disjoint Generic constraints expressed with First or higher order logic formulas:

Not supported


ISA: Subslot-of Equivalent: Not supported Reflexive*: Not supported Symmetric*: Properties symmetric Transitive*: Properties transitive Inverse*: Inverse Unique: Not supported


Not supported

Instances Multiple instantiation layers: 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.

Concept instance: Instance-of Relations between instances: related Equivalent: Not supported



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).


Synoptic table: XML-Schema Concepts Predefined categories: 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.

Constructors: AND: Not Supported OR : Union NOT: Not Supported Enumeration: Not Supported

Restriction: Various Restriction mechanisms are allowed for type derivation. Documentation: Documentation; appinfo; annotation

(These are elements explicitly defined to maintain documentation. In addition to these, the generic XML-style comment, <!—comment -->, may be used)



Attributes Instance attribute: <xsd:attribute name="attribute name" type="attribute type"

Default="default value"/>

Concept attribute: Not Supported Polymorphic: Yes Default slot value: Default (see above) Type: Type (see above) Cardinality: 1 Documentation: Not Supported Relations (Domain Relations) Relation name: 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


ISA: Not Supported

Equivalent: Not Supported Similar: Not Supported Part Of: Not Supported


Not Supported


ISA: Not Supported Equivalent: Not Supported Inverse*: N/A Reflexive*: N/A Symmetric*: N/A Transitive*: N/A Unique:

Inverse unique: Generic constraints expressed with First or higher order logic formulas:

Not Supported



Instances Multiple instantiation layers: 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.

Concept instance: See above. Relations between instances:

N/A

Equivalent: 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.


RDFS Concepts Predefined categories: rdf:Class Constructors:

AND: NOT EXPRESSIBLE OR : NOT EXPRESSIBLE NOT: NOT EXPRESSIBLE Enumeration:

Restriction: Documentation: rdfs:comment Attributes Instance attribute: 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.

Concept attribute: 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.

Polymorphic: No Default slot value: NOT EXPRESSIBLE Type: NOT EXPRESSIBLE Cardinality: NOT EXPRESSIBLE Documentation: rdfs:comment Relations Relation name: Cardinality: NOT EXPRESSIBLE Domain: rdfs:domain Range: rdfs:range Documentation: rdfs:comment Predefined Business Domain relations:

No




ISA: rdfs:subClassOf Equivalent: NOT EXPRESSIBLE Similar: NOT EXPRESSIBLE Part Of: NOT EXPRESSIBLE

Disjoint: NOT EXPRESSIBLE Generic constraints expressed with First or higher order logic formulas:

NOT EXPRESSIBLE


ISA: rdfs:subPropertyOf Equivalent: NOT EXPRESSIBLE Inverse*: NOT EXPRESSIBLE Reflexive*: NOT EXPRESSIBLE Symmetric*: NOT EXPRESSIBLE Transitive*: NOT EXPRESSIBLE Unique: NOT EXPRESSIBLE

Inverse unique: NOT EXPRESSIBLE Generic constraints expressed with First or higher order logic formulas:

NOT EXPRESSIBLE

Instances Multiple instantiation layers: 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.

Concept instance: rdf:type Relations between instances:

RDF triple Every RDF triple assets a property between two resources. In particular, resources may be instances.

Equivalent: NOT EXPRESSIBLE Comments


OWL Concepts Predefined categories: owl:Class, owl:ObjectProperty, owl:DatatypeProperty Constructors:

AND: owl:intersectionOf OR : owl:unionOf NOT: owl:complementOf Enumeration: owl:one of

Restriction: owl:Restriction,owl:onProperty, owl:allValuesFrom, owl:someValuesFrom, owl:hasValue, owl:minCardinality, owl:maxCardinality, owl:cardinality

Documentation: rdfs:comment



Attributes Instance attribute: owl:DatatypeProperty Concept attribute: owl:DatatypeProperty (in the concept definition, restriction with

the owl:hasValue constraint) Polymorphic: in the concept definition, restriction with the owl:allValuesFrom

constraint Default slot value: not supported Type: rdfs:range of the DatatypeProperty Cardinality: in the concept definition, restriction with the owl:cardinality

constraint Documentation: rdfs:comment Relations (Domain Relations) Relation name: owl:ObjectProperty Cardinality: only in the definition of a concept, by a restriction Domain: rdfs:domain Range: rdfs:range Documentation: rdfs:comment Predefined Business Domain relations:

not supported


ISA: rdfs:subPropertyOf Equivalent: owl:equivalentClass (we have also owl:differentFrom) Similar: not supported Part Of: not supported

Disjoint: owl:disjointWith Generic constraints expressed with First or higher order logic formulas:

all DL formulas


ISA: rdfs:subClassOf Equivalent: owl:equivalentProperty Reflexive*: not supported Symmetric*: owl:SymmetricProperty Transitive*: owl:TransitiveProperty Inverse*: owl:inverseOf Unique: owl:FunctionalProperty

Inverse unique: owl:InverseFunctionalProperty Generic constraints expressed with First or higher order logic formulas:

all DL formulas

Instances Multiple instantiation layers: supported only in OWL Full Concept instance: rdf:type ???? Relations between instances:

RDF triple (s,p,t) (Nota: questa è relation instance, non relation between instances…)

Equivalent: owl:sameAs



Comments


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: and OR : Not supported NOT: Not supported Enumeration: Not supported

Restriction: Not supported Documentation: Attributes Instance attribute: There is no way to express attributes of activities in PSL. Concept attribute: N/A Polymorphic: N/A Default slot value: N/A Type: N/A Cardinality: N/A Documentation: N/A Relations Relation name: 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.


Several business-domain relations.




ISA: Not Supported Equivalent: Not Supported Similar: N/A Part Of: Subactivity

Disjoint: Activities are either related through the subactivity relation or disjoint.


KIF axioms


ISA: Not Supported Equivalent: Not Supported Inverse*: Not Supported Reflexive*: Not Supported Symmetric*: Not Supported Transitive*: Not Supported Unique: Not Supported

Inverse unique: Not Supported Generic constraints expressed with First or higher order logic formulas:

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: Extensions to the PSL ontology may be defined with KIF axioms. Concept instance: ACTIVITY_OCCURRENCE Relations between instances: 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, leq-required,next-required-activity, mutually-occurring, start-synchronization, end-synchronization, full-synchronization, non-deterministic-choice,xor define relations between subactivities that express sequencing, partial or total overlapping (i.e. concurrency), synchronization etc.



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.




BPEL Concepts Predefined categories: Process

BPEL allows to define processes and their behaviors. These constitute the basic conceptual element expressible through its syntax.

Constructors: AND: Not Supported OR : Not Supported NOT: Not Supported Enumeration: Not Supported

Restriction: Not Supported Documentation: xml comment Attributes Instance attribute: 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

Concept attribute: Not Supported Polymorphic: Yes Default slot value: Yes

Variables can be initialized with values that are then used by all the instances of the process.

Type: MessageType, type, element (attributes) Cardinality: N/A Documentation: Xml comment Relations Relation name: 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).

Cardinality: 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.

Domain: 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.

Range: See the note for Domain. Documentation: Xml comment Predefined Business The PartnerLink relation represents a conversational relationship



Domain relations: between exactly two processes. The Partner relation represent a Partnership between two processes. A Partnership implies one or more PartnerLinks.


ISA: Not Supported Equivalent: Not Supported Similar: Not Supported Part Of: Not Supported


Not Supported


ISA: N/A Equivalent: N/A Inverse*: N/A Reflexive*: N/A Symmetric*: N/A Transitive*: N/A Unique: N/A

Inverse unique: N/A Generic constraints expressed with First or higher order logic formulas:

N/A

Instances Multiple instantiation layers: No Concept instance: 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

Equivalent: Not expressible



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.



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




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.


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.,


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.



[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.



[29] M. Dean, D. Connolly, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuiness, P. F. Patel-Schneider, 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.



[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 Well-Founded 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.



[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-concepts-20030123.

[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.



[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.



[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



[142] Semagix. Official web site. http://www.semagix.com



Section II Ontology management tools comparison



3 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.



3.2 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.



3.3 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. KAON Workbench

3.3.2 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.



Figure 5. Ontolingua web page

3.3.3 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



3.3.4 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 plug-ins) 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



3.3.5 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.



3.4 Survey results

Meta model features

KAON Protégé 2000 OilEd pOWL Ontolingua

Base Language

RDF(S). OKBC + CLOS based meta-models.

DAML+OIL. RDF(S) OWL.

Ontolingua.

Standards compatibility

1 – Only RDF(S) W3C recommended format is natively supported, not OWL.

3 – OWL plugin.

0 – DAML+OIL is not fully OWL compliant even though it originated OWL. They say DAML+OIL support is under development.

3 – OWL and RDF API.

2 - OWL, DAML and DAML-S areaxiomatized as ontologies. Chimaera accepts OWL and DAML.

Application Domain

adequacy and supporting

1 – Only classes and properties. No supporting.

1 – Highly expressive potential, but only general purpose templates.

1 – No supporting.



Constraints

1 – Simple constraints (e.g.: domain and relation range).

2 – OWL model constraints (e.g.:cardinality and relation attributes constraints such as: transitivity, symmetry...

2 – FaCT model constraints.

2 – OWL model constraints.

2 – OWL model constraints.

Advanced Queries

1 – Taxonomic reasoning (including specialization hierarchies).

2 - Taxonomic reasoning and equivalence relations.

1 - Taxonomic reasoning based on the CORBA-FaCT reasoner or subsumptions only.

3 – RDQL query builder and Fulltext search.

0 – No Taxonomic reasoner included.

Instance handling

3 3 0 3 3



Technical and functional features


Web Orientation

2 - Browsing ontologies via KAON Portal.

1 - standalone (local database) or client-server architecture (remote database) Web access (via applets) for browsing only.

0 3 - PHP based.

3 - Web based.

Multi User Support

1 - Concurrent Web access for browsing only. Remote connection to shared database. No check-in, check-out.

2 - Only when client is accessing a server DB: no check-in, check-out. “Metaproject” feature still under development.

0 - It is intended for a single-user ontology editing.

3 - It is for collaborative work.

1 - Write/Only access locks Ontology.

Web Services enabled

2 - It is possibleto create WSs via API.

2 - It is possible to create WSs via API.

0 3 - It is possible to access via WSs. Different pOWinstallations may share models by using Web Services.

0

Consistency Checks

2 2 - Plug-ins for adding & checking constraint axioms: PAL. FaCT.

1 - Only FaCT oriented checks such as subsumption.

2 - Elaborate with Chimaera; Theorem proving (via JTP).

Merging

0 2 - Semi automatic merging.

1 - Including Ontologies leads to heavy manual work.

2 - Semi-automatic via Chimaera.

Ontology Extraction

2 - Easy to use Text-to-Onto wizard.

0 0 0

Lexical Support

2 - Explicit lexical representation in model. Multilingual.

2 - Wordnet plugin enables API calls also with wildcards.

1 - Limited synonyms.

1 - Only Search of Terms in all loaded ontologies.

Query Tool 1 - Simple queries.

2 - Average complexity queries.

0 3 - RDQL query builder.

1 - Simple queries.




Graphical View(s)

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

Graphical Editing

0 2 - Separate plugins for editing nested graphic views.

0 2 - Web based graphic interface.

0

Import/Export formats

1 - Limited number of supported formats.

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.

2 - Limited number of supported formats (RDFS; SHIQ).

3 - Syntactically 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.

3 - Import & Export: DAML+OIL; KIF; OKBC; Loom; Prolog; Ontolingua; CLIPS. Import only: Classic; Ocelot; Protégé.

Log Facilities

0 0 1 - Only exceptions.

0 0

Versioning System

0 0 0 3 - Versioning system enables rollback of every editing action.

0



3.5 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.



4 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



4.2 Survey results

JENA [14] MetaLog [13] JESS [15] SWAP CWM [16] RACER [36]

Rule Base Language

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. OWL/FB reasoner:useful but incomplete implementation of the OWL/Lite subset of the OWL/Full language. Generic rule reasoner: it supports user defined rules, forward chaining, tabled backward chaining and hybrid execution strategies.

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 Pseudo-Natural-Language user interface.

CLIPS The core Jess language is still compatible with CLIPS, an expert system shell that inspired the JESS Java implementation.

RDF/N3 The Semantic Web Application Platform includes a Pyton-based rule processor called CWM.

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/DAML/OWL

OWL compatib.

1 - Not all OWL/Lite is supported, let alone full OWL. Works in progress focus more on stability and scalability than completeness.

0 0 - Planned in the future.

0 - Only RDF. Includes OWL vocabulary.

2 - OWL enabled.

Taxonomic Reasoning

0 - A distinct taxonomy construction phase is being planned.

0 0 0 0

Forward and Backward Chaining

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.

1 - Forward only.

Consistency Checking

3 - Rules Validation can be designed to

0 0 0 2



JENA [14] MetaLog [13] JESS [15] SWAP CWM [16] RACER [36]

run on demand.

Instance Checking

2 - Syntax Checking via beta plugin.

0 0 0 0

API Enabled

3 - For each reasoner there is a Java factory class, an instance of which can create instances of the reasoner.

0 3 - Jess is a Java scripting environment, from which you can create Java objects and call Java methods of the Jess object model.

1 - Only command line.

2 - APIs are available for Java, C++, and Common Lisp

Web Service Enabled

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 command-line calls with WSs.

2 - It is possible to wrap HTTP calls with WSs.

Rule Tracing

0 - Not internally. 0 0 - Improved error reporting is planned.

0 0

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).



5 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 frame-based 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



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.



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-of-concept 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.



6 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:



• 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.

6.2 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 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.

6.2.2 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.



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.

6.2.3 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.



webMethods - Integration Platform

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 JDBC-

compliant 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.

6.2.4 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.



6.2.5 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.



6.2.6 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 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



6.4 Survey results

IBM BizTalk TIBCO BEA Web Methods

SAP Netweaver

See Beyond

Vendor feasibilit

y

3 3 2 2 1 3 1

Product architect.

2 - HUB on J2EE

2 - .NET 3 - J2EE and .NET

2 – J2EE 3 – J2EE and.NET

Adapters

2 - J2EE Connector Architecture (JCA)

2 - Adapters for some commercial enterprise products, for SQL server, MQSeries and Web services

3 - Adaptors for the main databases and the main enterprise platforms

3 - Based on J2EE JCA and other pre-built adapters for MQ Series, databases and other enterprise products

3 - Adapters for enterprise products and for custom applications written in C/C++, COM, .Net, Java, and EJB

3 - Based on J2EE JCA, Web services and pre-built adapters for the most important enterprise products

Metadata

management

1 - Allows direct import of industry-standard or user-defined XML DTDs for mapping and translation

1 – Exists the concept of metadata but it is not possible to create taxonomies of metadata

2 - Enables creation of metadata to describe non-XML data

1 - E-business standards such as RosettaNet, UCCnet, SWIFT, ebXML and CIDX

Message protocol

2 - HTTP, SOAP, JMS

2 - Enables sending and receiving messages by using BizTalk Message Queuing, SOAP and HTTP

3 - Support for JMS, .NET, SSL, JNDI and Ldap

3 - HTTP(S), FTP and SMTP and message formats such as SOAP, XML RPC, ebXML, MIME and S/MIME

2 – HTTP, SOAP

3 - Support for Communication adapters (HTTP, SNA), Object oriented technology adapters (CORBA and Application server), Messaging



IBM BizTalk TIBCO BEA Web Methods

SAP Netweaver

See Beyond

(MQSeries, JMS, MSMQ)

BP and workflo

w support

2 - Provides pre-built solutions for business process automation and execution

3 – Graphical editor of business processes and BPEL suport

3 - Process management engine designed to meet the needs of organizations that need to handle extremely high mission-critical transaction

3 - Graphical business process editing and execution platform

3 - Innovative business process optimization capabilities ( BAM technology)

3 - Provides an open graphical modelling environment using BPMN and BPEL4WS

Web services enabled

3 - Full Web services support





3 – Full Web services support


XML enabled

3 - Supports optimized "any-to-any" transformat ion of EDI, XML, and record-oriented application data formats

3 - Full XML support and also EDI integration

3 - Full XML support

3 - Transformation of data between XML Data, Non-XML Data, Java Primitives, 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 management



6.5 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.

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.

6.6 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



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.uni-karlsruhe.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



[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.



Section III Ontology Contents



7 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).



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).

During the process of creating the terminology collection, information about each concept and its

Term Entry Pertains to one concept Documents terms assigned to the

concept One entry for each meaning of a

term Grammar only as related to term-

concept assignment Systematic concept structure

Definition more carefully related to other concepts

Facilitates translation by the ability to relate one concept to the terms for it in multiple languages

VEHICLE

NON MOTORIZEDVEHICLE

LAND VEHICLE

WATER VEHICLE

AIR VEHICLE

MOTORIZED VEHICLE

CARGO VEHICLE

PASSENGER AND CARGO VEHICLE

PASSENGER VEHICLE

CAR

D1

D2

D3

DIMENSIONS: D1 BY MEDIUM OF TRANSPORTATION D2 BY METHOD OF PROPULSION D3 BY PRINCIPAL TYPE OF LOAD CARRIED

Lexical Entry Pertains to one word Documents multiple senses of the word (for one etymology) Words with same spelling.(homographic), but with different derivations in different entries Provides grammatical information pertaining to word Alphabetic arrangement Definition based on general knowledge



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.



Figure 10. Types of Ontologies

TYPE Description Controlled vocabulary 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

Controlled vocabularies

Informalis-a

Terms/ glossary

Frames (properties)

Formal Instance

Value Restrictions

Formal is-a

Thesauri

Disjointness, Inverse, Part-of

General Logical

constraints



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 • eCl@ss 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



• 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 eCl@ss, 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 quoted from http://www.x12.org/x12org/about/X12Strategy.cfm 13 Quoted from http://www.gefeg.com/en/edifix/xml-spy.htm



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).

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 “

7.4 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



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



• 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.



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+Convergence+White+Paper.pdf



• 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



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.oasis-open.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-to-

human 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 re-usable 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].



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

Figure 12. 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

Person. Details Address. Details

Person. Person ID. Identifier Person. First Name. Text Person. Last Name. Text

Address. Street. Text Address. City. Text Address. State. Code

Person. Work. Address

Person. Home. Address

Person Address

Person ID: Identifier First Name: Text Last Name: Text

Street: Text City: Text State: Code

Work Address

Home Address



‘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 Secondary Representation

Term Amount. Type Amount Binary Object. Type Binary Object Graphic, Picture, Sound, Video Code. Type Code Date Time. Type Date Time Date, Time Identifier. Type Identifier Measure. Type Measure Numeric. Type Numeric Value, Rate, Percent Quantity. Type Quantity Text. Type Text 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 re-use. 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) Business Information Entity Type (BIE) Aggregate CC (ACC) Aggregate BIE (ABIE) Basic CC (BCC) Basic BIE (BBIE) Association CC (ASCC) 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.



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.

Figure 13. 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 Core Component Type (CC) and

example names Business Information Entity Type (BIE) and example names

Object Class Aggregate CC (ACC) Person. Details

Aggregate BIE (ABIE); An ABIE must be based on an ACC, and may be qualified. US_ Person. Details

Association between two classes

Association CC (ASCC) Person. Work. Address

Association BIE (ASBIE); An ASBIE must be based on a ASCC, and may be qualified. US_ Person. Work. US_ Address

Attribute/Property of Class

Basic CC (BCC) Person. First Name. Text

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 Attribute Data Type of BCC, which must be based on a Core Component Type

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.

US_ Person. Details US_ Address. Details

US_ Person. Person ID. US SSN_ Identifier US_ Person. First Name. Text US_ Person. Last Name. Text

US_ Address. Street. Text US_ Address. City. Text US_ Address. State. US State_ Code

US_ Person. Work. US_ Address

US_ Person. Home. US_ Address



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 Description Example Values Business Process The business process name.

It is intended that names come from the UN/CEFACT Catalogue of Common Business Processes.

Ordering Delivery

Product Classification The type of products involved in the business process, where ‘products’ can be material or immaterial, e.g., services.

Parts Consumer goods Consulting services

Industry Classification The industry or sub-industry in which the business process takes place.

Aerospace Fast Moving Consumer Goods

Geopolitical The locations of the participants in the business process

International Europe

Official constraints Legislation and regulations that apply to the business process

US law EU law

Business Process Role The roles played by the main participants in the business process. Like process names, the role names come from the UN/CEFACT Catalogue.

Buyer Seller

Supporting Role 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.

Shipping Agent

System Capabilities 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

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.



Context Category Relevant Standards Business Process UN/CEFACT Catalogue of Common Business Processes (work in

progress) Product Classification 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

Industry Classification International Standard Industrial Classification (ISIC), maintained by UNSD UNSPC top-level segment used to define industry others codes may also be used

Geopolitical Special structure that uses ISO 3166.1 for country codes and ISO 3166.2 for region codes.

Official constraints There is no known global classification system for this Business Process Role Role values from the UN/CEFACT Catalogue of Common

Business Processes Supporting Role UN/EDIFACT Code List for DE 3035 Party Roles System Capabilities 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 “open-source” 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-to-face 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.



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 supply-chain data. A second source is public 10K financial data available from sources like hoovers.com.



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.



Level Schematic Description Top Level

Level 1 defines the scope and content of the model as well as performance attributes and metrics.

Configuration Level

A supply chain can be "configured-to-order" at Level 2 from the core process categories which are variants of the Level 1 processes.

Process Element Level

Level 3 Example:

Level 3 decomposes Level 2 process categories into process elements and their associated inputs, outputs, metrics and best practices.

Implementation Level

Not in scope Level 4 is the implementation level and is outside the scope of the model.

Figure 14. SCOR Hierarchical Model

S1 Source Stocked

Inputs

Process Elements

Output

PP11 PPllaann SSuuppppllyy CChhaaiinn PPllaann

S3

S2

S1

M3

M2

M1 D1D2D3D4

P2 P3 P4 P5

SSoouurrccee MMaakkee DDeelliivveerr

3

4

2

1

Return

Source Make Deliver

Plan

ReturnSupp

liers

Cus

tom

ers

Enable



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.



Figure 16. Example Thread Diagram



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



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 Deliver Return

- Identify Sources

- Source Negotiate

- Schedule Delivery

- Receive Product

- Verify Product - Transfer

Product - Authorize

Payment

- Finalize Engineering

- Schedule Production

- Issue Product - Produce &

Test - Release

Product

- 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

- Identify Excess Inventory

- Authorize Return

- Verify Condition

- Transfer Return

- Disposition & Recover

- Replace or Credit

Plan Enable

- Identify Requirements

- Assess Resources

- Balance Demand

- Communicate Plan

- Rules - Performance - Information - Inventory - Assets - Transportation - Network

Config - Import/Export - Regulatory

Comply - Product

Lifecycle - Agreements

Table 3. 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)



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



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



[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


Strategic Objective



Acronym

ATHENA Project No



A3



Modelling Language. Part B: The Athos specifications



March 16th, 2005

Version 1.0

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Knowledge Support and Semantic Mediation Solutions ATHENA - Project Number A3 Document Deliverable A3.1 Part B Date 04.04.05

050404_ATHENA_DA31_PartB_V10.doc/derek CONFIDENTIAL Page 137 / 244

Versioning and contribution history Version Description Comments

0.1 Structure of the document 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).



1



2



27.08.2004




14.01.2005



28.01.2005





21.03.2005 31.03.2005

9 Submission to Commission Programme Office 04.04.2005



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 149 4.3.1 Identification Section 149 4.3.2 Structural Section 149 4.3.3 Object Specific Section 151 4.3.4 Process Specific Section 151 4.3.5 Actor Specific Section 151 4.3.6 Message Specific Section 152 4.3.7 Business Object Document Specific Section 152 4.3.8 Atomic Attribute Specific Section 153 4.3.9 Complex Attribute Specific Section 153 4.3.10 Operation Specific Section 154

5 Formalization of the OPAL Meta-Model 155 5.1 OPAL Abstract Syntax 155

6 Building a consistent ontology 159 6.1 OPAL Relations and inherent constraints 159 6.1.1 Generalisation (ISA) 159 6.1.2 Predication (Pr) 159 6.1.3 Decomposition (D) 160 6.1.4 Relatedness (R) 160

7 OPAL Semantics 162 7.1 The OPAL Semantics in OWL-DL 162 7.1.1 Identification Section 162 7.1.2 Structural Section 163 7.1.3 Specific Section 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 The Athos GUI 176 10.2 The Application tier 177 10.2.1 The Client Manager 177 10.2.2 The GUI Manager 177



10.2.3 The Application Logic Module 178 10.2.4 The Database Access Manager 179 10.3 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 182 11.3.1 ZExtension Point Description 183 11.4 The Athos Plug-in development 183 11.5 Plug-ins registration 184 11.5.1 Athos plug-in map 185 11.5.2 How to develop a new Athos plug-in 186

12 Athos web services 188 12.1 Introduction to web services 188

13 Zope: A Web Publishing Framework 190 13.1 Zope Components 190 13.1.1 ZPublisher 190 13.1.2 HTML document templates 190 13.1.3 Object database (ZODB) 190 13.2 Why Use Zope Instead of Another Application Server 190

14 Conclusions and Future Work 192

15 Appendix A 193

16 References 195



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 CONFIDENTIAL Page 141 / 244

1 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



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).



2 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 meta-concepts are located on the top layer, super-concepts are on the middle layer and ground instances are on the lower layer.



Figure 1. 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).



3 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



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.



4 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. Purchase-Order-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



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.

Order ProcessingBuyer Process Supplier Process

EvaluatingQuotation

Issuing PO

Receiving Goods

BUYER SUPPLIER

Paying Invoice

Sending RFQ RFQ

Quot.

PurchaseOrder

Del Not

Invoice

Processing RFQ

Processing PO

Fulfilling PO

Delivering Goods

Invoicing

Figure 2. The Order Processing example



4.3 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 References:Merriam_Webster Defined_Updated: 02-04-04

4.3.2 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,



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 OrderLine: cardinality>=1; OrderDate: type=string; cardinality=1; DeliveryDate: type=string; cardinality=1;

PaymentTerms: type=string; Values={cash, cheque, credit card}; cardinality=1; TransportTerms: type=string; Values={by rail, by road, by sea}; cardinality=1; DeliveryNote: cardinality=0..1;

Invoice: cardinality=0..1; Relatedness additional features Invoice: 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



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);



• 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



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.



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 meta-model. 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.



5 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};



• 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.


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’};



• 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


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), Content(mi), PrecedingMessages(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};

BusinessObjectDocumentSpecSecti = [AuthoredBy(bi), CarriedBy(bi)] • AuthoredBy(bi) = {a | (bi, a), a ∈ Ar}; • CarriedBy(bi) = {m | (bi, m), m ∈ M};

AtomicAttributeSpecSecti = [Domain(ti), Range(ti), EquivalentTo(ti), Functional(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”}

ComplexAttributeSpecSecti = [Domain(ci), EquivalentTo(ci), Functional(ci), InverseFunctional(ci)] • Domain(ci) = {c | (ci, c), c ∈ Ar ∪ O ∪ P∪ M∪ BOD};



• 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.



6 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.



6.1.3 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,

(ci,ch) ∈ S ⇒ kind(ci) = O C11) Let S be a relation in the Process Specific Sections,

(ci,ch) ∈ S ⇒ kind(ci) = P C12) Let S be a relation in the Actor Specific Sections,

(ci,ch) ∈ S ⇒ kind(ci) = A C13) Let S be a relation in the Message Specific Sections,

(ci,ch) ∈ S ⇒ kind(ci) = M C14) Let S be a relation in the Business Object Document Specific Sections,

(ci,ch) ∈ S ⇒ kind(ci) = BOD C15) Let S be a relation in the Complex Attribute Specific Sections,

(ci,ch) ∈ S ⇒ kind(ci) = CA C16) Let S be a relation in the Atomic Attribute Specific Sections,

(ci,ch) ∈ S ⇒ kind(ci) = AA C17) 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



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.



7 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, OWL-DL 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;


Below we show some elements of the Identification Section, represented by means of OWL constructs.

Concept label rdfs:label Concept description rdfs:comment



XMLtag <XMLtag> a owl:DatatypeProperty; rdfs:domain [ a owl:Class; owl:unionOf (<ACTOR> <OBJECT> …)]; rdfs:range xsd:String.


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.

ISA Rdfs:subClassOf Predication <PREDICATION> a owl:ObjectProperty; Decomposition <DECOMPOSITION> a owl:ObjectProperty; Relatedness <RELATEDNESS> a owl:ObjectProperty;

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

Rel_name rdfs:id Inv_rel_name rdfs:id

7.1.3 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 <GOALS> a owl:ObjectProperty; Skills <SKILLS> a owl:ObjectProperty; Responsabilities <RESPONSABILITIES> a owl:ObjectProperty;



Cooperations ( <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( rdfs:domain Range ( rdfs:range Functional ( owl:FunctionalProperty; InverseFunctional ( owl:InverseFunctionalProperty;

7.2 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 [



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>].



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>)

]].



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



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.

Steps of the transformation: 1) Let O be the OPAL ontology 2) Build a namespace for the ontology O 3) Import the file containing the definition of the OPAL model 4) 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.



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>.



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”:



<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:



<hasPart_ItemId> rdfs:range <xsd:String>.



8 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.



9 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.

System Requirements System specifications 1 Web orientation, in order to be used

remotely, without needing any specific client • 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) 4 Controlled access to an ontology • 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. 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 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)

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

Guided definition of a concept • 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.

Ontology navigability • 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



3 Ontology consistency checking • 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.

Keeping track of the work (who does what) Athos provides a log functionality in order to: • 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

Knowledge export • 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

Keeping track of the documental resources • 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

Report production • 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

Web services support • 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)

Extendibility of functionalities • Athos provides a plug-in architecture in order to ease future extensions and to develop new functionalities.



10 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.

Ontologies

Ontologies

UsersadminUsersadmin

Instances

Instances LogLog

Athos DBs

Clienttier Athos

Servertier

Databasetier

Diagrammingtool

Reportingtool

Othersystem

Validationtool

(Web Services)

SOAP

SOAP

Internet

InternetHTTP

WS connector

AthosGUI

Othersystems

Client Manager

Application Logic

DB AccessMngr

Figure 3. 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.



Figure 4. 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.



Sessions Manager

Athos gateway

CommunicationSystem

PageTemplates

GUIGenerator

Application Logic

Client Manager

Web browser(Athos GUI)

Other Systems(SOAP clients)

HTMLpages

Page data

SOAPsupport

HTTP SOAPInternet

Figure 5. 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..



Ontology Manager Admin Manager

Request Dispatcher

Constraints CheckingModule

ErrorManager

Database Connector

ApplicationLogic

Client Manager

Import/Export module

QueryProcessor

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.



11 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 plug-

in extends the functions of the host plug-in.

Figure 7. The Eclipse plug-in relationships and roles

5 http://www.eclipse.org/



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, slot-widget 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);



• 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.

Core Service Plug-inuses

depends on

Host Plug-in Extender Plug-in

ZExtension Pointexposes

ZExtension Point Description

isConnectedTo

isDescribedBy

1

*

1

*

1

1

* *

*

*

Figure 10. The Athos plug-in Framework



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.



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.



Figure 11. Plug-in registration – two ZExtension Points

Figure 12. Plug-in registration – two Extender plug-ins

11.5.1 Athos plug-in map

Two Extender Plug-ins



Athos Gui

ConceptList

MenuBar

ConceptInfo

Navigation Bar

Specialisation Hierarchy Decomposition Hierarchy Search

RelationView

Figure 13. 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;



• 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.



12 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;



• 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.



13 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 Zope Corporations and enjoys a large and very active development community

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



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.



14 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.



15 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 --



> <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>



16 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

D.A3.1- Part 3 - Athos Manual V1.0 CONFIDENTIAL Page 196 / 244

Programme

Integrating and Strengthening the European Research Strategic Objective

Networked business and government Integrated Project / Programme Title


Acronym ATHENA

Project No



A3



Modelling Language. Part C: The Athos User Manual



March 16th, 2005

Version 1.0

IP- Project A T H E N A 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 Comments

0.1 First release

0.2 Internal review

1.0 Final version



1

Initial drafting of the deliverable

including structure, comments and first

basic content to be sent to to-be-

contributors.

F. Taglino (CNR)

M.Missikoff (CNR) 05.07.2004

2

First round of contributions. Work

package member and others to

contribute first iteration to owner of

the deliverable

F.Taglino (CNR)

D. Gazzotti

(Formula)

S-M Thomas (SAP)

27.08.2004

3 Owner to consolidate first round input

and distribute to contributors F. Taglino (CNR) 22.10.2004

4

Final round of contributions including

comments form peers/AL to be sent to

owner

F.Taglino (CNR)

L. Pondrelli

(Formula)

S-M Thomas (SAP)

E. Coscia (TXT)

F.W. Jaekel (IPK)

14.01.2005

5

Final consolidation of input and

finalisation of “technical” document to

be send to

F. Taglino (CNR)

M. Missikoff (CNR)

G. Callegari (CNR)

28.01.2005

6 Quality check – e.g. Peer Review Elmar Dorner (SAP) 14.03.2005

Only part B has been revised. We

didn’t receive any feedback for Part A

and B.


8

Final Approval from partners or

delegates to be send to Programme

Office

PCC members or

delegates: Guy

Dougmeings (itrec)

Joerg Muller

(Siemens)

21.03.2005

31.03.2005

9 Submission to Commission Programme

Committee





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





4.5 The Structural Section panel 220

5 Ontology User Functions 221

5.1 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 The search function activation 227

5.5 The glossary mode function 228

5.5.1 Glossary mode 228

5.5.2 Export glossary function 229

5.6 Print a concept 230

6 The Ontology Master Functions 231

6.1 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





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





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





1 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.





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].





2 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.





2.2 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.





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-Slot-

Facet 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






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


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.





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;





• 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






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


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.





3 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.





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.

.





Figure 2. 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.





Figure 3. Login page

3.5 Athos Logout

In order to disconnect (log out) a user from a given ontology, a user has just to close the browser

window.





4 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. The Athos standard interface - Menu bar

4.1 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





4.2 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.





4.3 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.





4.4 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).





4.5 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





5 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





5.1 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.





5.1.2 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.





5.1.3 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.





5.2 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





5.3 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





5.4 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.





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.





Figure 17. The Glossary display

5.5.2 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





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. Glossary List

5.6 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.





6 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.





6.1 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).





Figure 21. Creation of a new concept -

The Identification Section


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;





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).


The Structural Section


The Structural Section(cont’d)

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).






Attribute addition


Attribute addition (cont’d)

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





data to compose the Structural tree of the new concept (Figure 27 for up and Figure 28 for down

area).


Specific Section


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.





6.2 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-

Identification example


Identification example (cont’d)

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.





In both alternatives, the Athos system supports user by opening a popup sub-panel (Figure 32).


Structural example

Figure 32. 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).





Figure 33. 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.





Figure 34. Creation of a new concept- Display of the inserted concept

6.3 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)





Figure 35. Editing an existing concept

Figure 36. Editing an existing concept

(cont’d)





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).





Figure 37. 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.





7 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





8 References

[1] “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.