- Email: [email protected]
A Reference Lexicon Definition from Fact Models
Proceedigs on Proceedigs of of the the 15th 15th IFAC IFAC Symposium Symposium on Available online at www.sciencedirect.com Information Control Problems in Manufacturing Information Control Problems in Manufacturing Proceedigs of the 15th IFAC Symposium on May 11-13, 2015. Ottawa, Canada May 11-13, 2015. Ottawa, Canada Information Control Problems in Manufacturing May 11-13, 2015. Ottawa, Canada
ScienceDirect
IFAC-PapersOnLine 48-3 (2015) 300–307
A Reference Reference Lexicon Lexicon Definition Definition from from Fact Fact Models Models A A Reference Lexicon Definition from Fact Models Pedro Andrade*. Andrade*. Joao Joao Sarraipa* Sarraipa* Pedro Ricardo Jardim-Goncalves* Ricardo Jardim-Goncalves* Pedro Andrade*. Joao Sarraipa* Ricardo Jardim-Goncalves*
*CTS, *CTS, UNINOVA, UNINOVA, Dep.º Dep.º de de Eng.º Eng.º Electrotécnica, Electrotécnica, Faculdade Faculdade de de Ciências Ciências ee Tecnologia, Tecnologia, FCT, FCT, Universidade Universidade Nova Nova de de Lisboa, Lisboa, 2829-516 Caparica, Portugal; (e-mail: [email protected]; [email protected]; [email protected]). 2829-516 Caparica, Portugal; (e-mail: [email protected]; [email protected]). *CTS, UNINOVA, Dep.º de Eng.º Electrotécnica, Faculdade de Ciê[email protected]; e Tecnologia, FCT, Universidade Nova de Lisboa, 2829-516 Caparica, Portugal; (e-mail: [email protected]; [email protected]; [email protected]). Abstract: Nowadays, Nowadays, it it has has been been noticed noticed an an increased increased demand demand for for interoperable interoperable systems systems capable capable of of Abstract: exchangingNowadays, information within collaborative businessdemand environments. Consequently, cooperation exchanging information within business environments. Consequently, Abstract: it has been collaborative noticed an increased for interoperable systems cooperation capable of agreements between between each of ofwithin the involved involved enterprises have been been brought to to light. light. However, due duecooperation to the the fact fact agreements each the enterprises have brought However, to exchanging information collaborative business environments. Consequently, that even in a same community or domain, there are a big variety of business concept models that are not that even in between a same community domain,enterprises there are ahave big variety of business concept models arefact not agreements each of theor involved been brought to light. However, duethat to the semantically coincident, which embodies the need of an enterprise reference lexicon definition for semantically whichorembodies the need enterprise reference lexicon definition for that even in a coincident, same community domain, there are a of bigan variety of business concept models that are not interoperable communications establishment. This paper proposes an approach that addresses the interoperable communications approach that addresses semantically coincident, which establishment. embodies the This need paper of an proposes enterprise an reference lexicon definition the for automation in in communications the information information models models mappingThis and the the reference lexicon construction. Itaddresses aggregatestheaa automation the mapping and reference lexicon construction. aggregates interoperable establishment. paper proposes an approach that It formal and and conceptual conceptual representation ofmapping the business business domain, with lexicon clear definition definition of the the used lexicon lexicona formal representation the domain, with aa clear of used automation in the information modelsof and the reference construction. It aggregates to facilitate a further and overall understanding of the business model. to facilitate a further andrepresentation overall understanding of the business formal and conceptual of the business domain, model. with a clear definition of the used lexicon to a further and overall understanding ofIntegration; theControl) business model. © facilitate 2015, IFAC (International Federation of Automatic Hosting by Elsevier Ltd. All Representation. rights reserved. Keywords: Enterprise Interoperability; Semantic Data Models, Knowledge Keywords: Enterprise Interoperability; Semantic Integration; Data Models, Knowledge Representation. Keywords: Enterprise Interoperability; Semantic Integration; Data Models, Knowledge Representation.
1. 1. INTRODUCTION INTRODUCTION 1. INTRODUCTION The The globalization globalization of of the the business business market market is is aa reality reality that that we we face at the present day. Although the positive effects that face at the present of day. positive this The globalization theAlthough business the market is a effects reality that that this we phenomena has to as direct phenomena has provided provided to the thethecommunity, community, as aathat direct face at the present day. Although positive effects this consequence or after small consequence or provided after effect effect of this, small and and medium phenomena has to of the this, community, as amedium direct enterprises (SME) have found themselves to be enterprises haveeffect foundofthemselves to be inevitably consequence(SME) or after this, small andinevitably medium choked by industry’s so “big order choked by the the industry’s so called called “big fishes”. fishes”. Ininevitably order for for enterprises (SME) have found themselves to beIn those SME enterprises to keep in business and to maintain those SME enterprises to keep in business and to maintain choked by the industry’s so called “big fishes”. In order for their they increase their and their credibility, they must must increase their competitiveness competitiveness and thosecredibility, SME enterprises to keep in business and to maintain productivity, which aa greater efficiency productivity, which requires greater efficiency on on their their their credibility, they requires must increase their competitiveness and processes and management. Thus, it has been realized by processes andwhich management. it hasefficiency been realized by productivity, requires Thus, a greater on their these enterprises that success would only come through the these enterprises that success Thus, woulditonly processes and management. has come been through realized the by establishment of each establishment of cooperation cooperation agreements among each other. other. these enterprises that success agreements would onlyamong come through the However, due to worldwide diversity the However, due of to the the worldwide diversity of ofamong the communities, communities, establishment cooperation agreements each other. aaHowever, high number of knowledge representation elements, such high number of the knowledge representation such as as due to worldwide diversity of elements, the communities, business concept models and ontologies, which are not business concept models and ontologies, which are a high number of knowledge representation elements, suchnot as semantically coincident, have appeared representing semantically coincident, have appeared representing the same business concept models and ontologies, which the aresame not segment of (Sarraipa al., a). segment of reality reality (Sarraipa etappeared al., 2010 2010 representing a). As As aa consequence consequence semantically coincident, haveet the same of that, enterprises have faced many problems trying of that, enterprises have faced problems when trying to to segment of reality (Sarraipa et many al., 2010 a). As when a consequence communicate with each other, since most likely none of communicate with each since most likelywhen nonetrying of their their of that, enterprises have other, faced many problems to systems or uses the to their systems or actors actors uses other, the same same lexicon to represent represent communicate with each sincelexicon most likely none of their domain domain ofordiscourse. discourse. systems of actors uses the same lexicon to represent their domain of discourse. To To contribute contribute to to solve solve this this interoperability interoperability issue, issue, the the authors authors propose an approach for the establishment of an enterprise propose an approach for the establishment of an enterprise To contribute to solve this interoperability issue, the authors reference from concept reference lexicon fromforbusiness business concept models, models, addressing propose anlexicon approach the establishment of an addressing enterprise the the models mapping for the automation automation infrom the information information models mapping for the the reference lexiconin business concept models, addressing reference lexicon construction. This approach aggregates reference lexicon Thismodels approach aggregates the automation in construction. the information mapping for theaa formal and conceptual representation the domain formal andlexicon conceptual representation of the business business domaina reference construction. This of approach aggregates and gives a clear definition of the used lexicon to facilitate an and gives clear definition of the usedoflexicon to facilitate an formal anda conceptual representation the business domain overall understanding by all the involved stakeholders (e.g. overall understanding by all stakeholders (e.g. and gives a clear definition of the the involved used lexicon to facilitate an modellers), including (Information Technology) modellers), including bynon-IT non-IT (Information Technology) overall understanding all the involved stakeholders (e.g. personnel. personnel. modellers), including non-IT (Information Technology) personnel.
Consequently, Consequently, to to introduce introduce such such proposed proposed approach, approach, the the paper first presents the type of business concept model paper first presents the typesuch of business model Consequently, to introduce proposed concept approach, the addressed this also the some addressed bypresents this research research also with with the clarification clarification ofmodel some paper firstby the type of business conceptof of its concepts. Then proposed reference lexicon of its related related concepts. Then the proposed reference of lexicon addressed by this research alsothe with the clarification some establishment approach from fact models is explained. establishment approachThen fromthefact models is explained. of its related concepts. proposed reference lexicon Afterwards, architecture aa prototype on Afterwards, theapproach architecture of fact prototype based on the the establishmentthe fromof models based is explained. approach defined plus a use case demonstration is described. approach defined plus a use case is described. Afterwards, the architecture of demonstration a prototype based on the Finally some some conclusions with future steps on on this this research Finally conclusions steps research approach defined plus a usewith casefuture demonstration is described. work are presented. work aresome presented. Finally conclusions with future steps on this research work are presented. 2. 2. USING USING FACT FACT MODELS MODELS FOR FOR CONCEPTS CONCEPTS EXTRACTION EXTRACTION 2. USING FACT MODELS FOR CONCEPTS EXTRACTION Nowadays, Nowadays, enterprises enterprises are are embracing embracing the the ICT ICT (Information (Information and Communications Technology) era, which has and Communications has pushed pushed Nowadays, enterprises Technology) are embracingera, thewhich ICT (Information them for the integration of Enterprise Modelling (EM) related themCommunications for the integrationTechnology) of Enterprise era, Modelling related and which (EM) has pushed systems or solutions to support the enhancement of their systems or solutions theModelling enhancement their them for the integrationtoofsupport Enterprise (EM)ofrelated business activities. This is in line with Ambler statement business activities. This is in line with Ambler statement systems or solutions to support the enhancement of their about EM (Ambler, 2015), which even seeming about EMactivities. (Ambler,This 2015), which says that evenstatement seeming business is in line says with that Ambler superfluous, formally documenting the business that superfluous, formally2015), documenting the that business that an an about EM (Ambler, which says even seeming organization engages in will lead to many interesting organization engages documenting in will lead the to business many interesting superfluous, formally that an conversations about should and, conversations about how how things should really work and, organization engages in things will lead to really many work interesting ultimately, to a shared understanding of exactly what ultimately, a shared of exactly conversationsto about how understanding things should really work what and, business the enterprise are and the business the to enterprise are in inunderstanding and how how it it execute execute the work. work. ultimately, a shared of exactly what business the enterprise are in and howmore it execute the work. Thus, Thus, it it could could be be said said that that to to be be more efficient efficient an an ICT ICT enterprise needs to model its business to assure advanced enterprise needs to model its business to assure advanced Thus, it could be said that to be more efficient an ICT functionalities in its systems. is process building functionalities in to its model systems. EM is the the to process ofadvanced building enterprise needs itsEM business assureof models of whole or part of an enterprise with business models of whole part ofEM an isenterprise with functionalities in itsorsystems. the process of business building models, models, data resource models and models, process process models, dataofmodels, models, resource with models and or or models of whole or part an enterprise business new ontologies etc. (Vernadat, 1997). A business model new ontologies (Vernadat, 1997).resource A business model can models, process etc. models, data models, models andcan or be as top-level model that the be defined as aa etc. top-level model1997). that defines defines the enterprise’s enterprise’s newdefined ontologies (Vernadat, A business model can strategic which all the others derive. strategic plan, from which all that the defines others models models derive. be definedplan, as a from top-level model the enterprise’s Among the various models, there is the business entity model Among various models, business entityderive. model strategicthe plan, from whichthere all is thetheothers models type or Fact Model, which structures business knowledge type or Fact Model, which structures business knowledge Among the various models, there is the business entity model type or Fact Model, which structures business knowledge
2405-8963 © 2015, IFAC (International Federation of Automatic Control) Hosting by Elsevier Ltd. All rights reserved. Peer review under responsibility of International Federation of Automatic Control. Copyright 321 Copyright © © 2015 2015 IFAC IFAC 321 10.1016/j.ifacol.2015.06.098 Copyright © 2015 IFAC 321
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
301
2.1 ORM 2 – Object Role Modelling
about core business concepts and business operations (ModernAnalist.com, 2012).
Object Role Modelling is a fact-oriented data modelling technique proposed by Terry Halpin in 1989 (Halpin, 1989) (Halpin and Bloesch, 1998) for performing information analysis at the conceptual level, where the application is described in terms easily understood by non-technical users. In practice, ORM data models often capture more business rules, and are easier to validate and evolve than data models in other approaches (Halpin, 2014). Unlike the EntityRelationship (ER) modelling and Unified Modelling Language (UML) class diagrams, fact-oriented modelling is attribute-free, treating all elementary facts as relationships, which facilitate verbalization in sentences and highlight connectedness through semantic domains.
This paper focuses on the situation of enterprises collaboration and cross-organizational business processes establishment, which requires systems with seamless interoperable communications. Since, a good Fact Model tells you how to structure your basic thinking (or "knowledge") about the business process based on a standard vocabulary (Ross, 2000), it is requisite to address a case of having enterprises’ fact models acting as inputs of a reference lexicon definition for the establishment of semantic agreements between organisations. A Fact Model is a business-oriented representation of the domain key concepts (Purchase, 2010). This kind of models must include all the structure of the company, describing how the company creates, delivers and captures value. Additionally, they have the goal of structuring the essential knowledge about business operations in a more user-friendly way, using standard vocabulary and thus allowing the expression of each element of the business terminology in a design-independent fashion, making it possible for non-IT stakeholders to participate more actively on the development. To help ensure correctness, clarity, adaptability and productivity, information systems are best specified first at the conceptual level, using concepts and language that people can readily understand (Halpin, 2001).
This method simplifies the design process by using CNL, as well as intuitive diagrams, which can be populated with examples, and by examining the information in terms of elementary facts, that are named, atomic fact (Halpin, 2001). By expressing the model in terms of natural concepts, like objects and roles, it provides a conceptual approach for modelling. Object Role Modelling views the world as a set of objects (entities and values) that play roles (their parts in each relationship). These are the most elementary elements of the ORM conceptual schema.
Consequently, if these indications are followed all the business stakeholders will naturally accept and understand the language used to define the vocabulary of such formal business representations. In this sense, a Fact Model can be a starting point for developing the next steps of business knowledge, as constraints and rules. This type of model focuses on logical basic connections (called Fact Types) between core concepts (represented by Terms) of the business in an intuitive manner. Besides the fact that businesses are runing on rules, fact types bring lots of benefits, making the visualization of all the business concepts very intuitive, even for non-IT personnel.
Fig. 1. Simple predicate expression with ORM. As it is possible to verify in this small ORM scheme, Person is an object type and is illustrated as a continuous line rectangle, having a reference scheme “(.name)”. This means that a Person is identified by its name. The term depicted as a dashed rectangle is a value type and the middle rectangle is the predicate that connects the two terms. In this case, there are two rectangles, as there are two different roles represented (binary fact type), one for each direction of read. The defined fact types of this simple example are: “Person has Age” from left to right, and “Age is of Person” from right to left.
In order to understand the difference between a fact type and a rule in a more clear way, if we were to pick for instance, the fact type “customer places order” and then extend it to “customer places at least one order”, then we would be adding a constraint to the fact type and thus, creating a rule.
The bar over the first role is used to define an internal uniqueness constraint. These constraints declare that instances for that role in the fact type population must be unique. With that said, it means that, for instance, in Fig.1, the constraint on the “has” predicate verbalize that a Person cannot have more than one Age value but that it is possible for the same Age to be given to more than one Person.
Fact based modelling has been researched and applied in business of semantic modelling for information systems since the 70s as a way to model, query and transform facts using attribute-free structures based on Constrained Natural Language (CNL). Subsequently, several developments have taken place in parallel, resulting in several fact based modelling “dialects”, including NIAM, ORM2, DOGMA and FCO_IM (Fact Based Modeling WG, 2011). The authors made a short comparison between each of these languages and due to the existence of an API accomplished by an active support community the authors decided to focus their analysis and prototype development in ORM2 language.
Finally, to finish this example, the dot placed on the “has” predicate is a mandatory role constraint. What that constraint does is to define that each Person needs to have some Age value. It is a relationship that needs to exist in order for the business model to function properly.
322
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
302
These are the most basic functionalities of the ORM language. Of course, ORM has a very vast list of possible constraints to be used.
2015). Furthermore, it allows other operations such as track changes, chat, comments on ontology changes, voting, etc. The OntoWiki tool is a collaborative environment that supports the visual presentation of an ontology as an information map, with different views on instance data (Auer et al., 2006). It uses particular functionalities as: Change tracking, Commenting, Rating, Popularity and Activity/Provenance. Additionally, it enables intuitive authoring of semantic content, with an inline-editing mode for editing RDF content, similar to WYSIWYG (What You See Is What You Get) for text documents (Dietzold, 2011).
3. ESTABLISHING A REFERENCE LEXICON The definition of a reference lexicon has the main objective of establishing a set of concepts with shared meanings to be representative of a certain domain and community. Then such community systems or actors can use them in business descriptions facilitating the semantic interoperability establishment. However, due to a natural behaviour of a system, such lexicon shouldn’t be considered fixed, thus it should be passible of modifications on its lifetime requiring semantic adaptations capabilities.
The NeOn methodology has the main objective of improving the capability to handle multiple networked ontologies that are created collaboratively, and might be highly dynamic and constantly evolving (NeOn Project, 2010). This methodology integrates a set of different building ontology scenarios accomplished with documented procedures to guide users developing their ontologies using the NeOn Toolkit.
Additionally to the reference lexicon establishment, some common standards as: Standard for the Exchange of Product model data (STEP), or OWL (Web Ontology Language) could be used. Thus, apart of using a standard to formalise a product, a process or a message, the lexicon mentioned still being necessary to represent such standards specific elements as naming and descriptions (contents) ensuring their common understanding.
It was identified that from all the presented methodologies NeOn methodology and its associated tool is the one that addresses all the mentioned requirements, but without aggregating all the mentioned characteristics in a methodology as an all. It does not fulfil the process of supporting enterprises to establish a common view on their semantics, establishing at the same time mappings tables of the reached semantic agreements. Thus, the communications between old semantic and new semantic systems are not facilitated neither its translations nor transformations. From this, it was identified the necessity of having a methodology focused on supporting the building of a reference ontology able to represent all the actors semantics, but at the same time that could let enterprises still work with their traditional and old semantics.
Ontologies are widely used as formal devices to represent the lexical content of words (Lenci, 2002). Aligned to this, authors proposed the definition of a reference lexicon through an ontology building methodology. Thus, also based on the previous statements, it was identified some requirements to which such methodology should answer to. It should support the ontology collaborative building enriched with Qualitative Information Collection Methods (QICM) to support collaborative definitions and decisions. Additionally, such methodology should be able to facilitate the ontology building from scratch and by reengineering of existent ones. The collaborative building of ontologies uses merging or integration functionalities supported by the establishment of mappings between existent ontologies and the new built one, enabling the traceability of the knowledge evolution allowing keep in use old semantic representations if needed. Based on these requirements it was identified some collaborative ontology building tools and methodologies presented in the following.
Consequently, MENTOR (Methodology for Enterprise Reference Ontology Development) was the methodology chosen. It is a methodology that allows the construction of a reference ontology of in a collaborative environment, enabling all the involved stakeholders to share their knowledge and combine it in order to come to an agreement about all the terms and relations that will be included in the business domain (Sarraipa et al., 2008). MENTOR also operates as an intermediate between each of the source data models, allowing the involved stakeholders to maintain their own business models.
The Iterative Collaborative Ontology Construction (ICOC) scheme, supports the online collaborative knowledge contribution by using a wiki-like application supported by a Delphi-like method to converge the answers to an automatic generated questionnaire to construct a uniform ontology (Lin et al., 2007).
The MENTOR methodology is composed by two phases that have three steps each. A diagram of this methodology is presented in Fig.2. The first phase of this methodology, named Lexicon Settlement Phase, consists on the knowledge acquisition phase. This phase is comprised by the following steps (Sarraipa et al., 2008):
Holsapple and Joshi in (Holsapple and Joshi, 2002) also uses a Delphi-like method in four phases to structure collaborative discussions to reach consensus, demonstrating the ontology use at its ending phase.
- Terminology Gathering: In this first step, MENTOR receives all the relevant and necessary terms from all the involved stakeholders and tags each term with the name of the respective contributor.
Collaborative Protégé is an extension of the existing Protégé tool to support collaborative ontology editing, where the changes made by a user are reflected on the repository, enabling other users see the changes on the fly (Tudorache,
- Glossary Building: In this step, MENTOR requests a description of each of the previously added terms. After 323
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
having each of the participants manually providing this information, a voting process takes place. In this process, each participant review the descriptions uploaded by all other participants and choose the one that seems the most proper. At the end of this process, if all the stakeholders came to an agreement, the chosen terms are defined as reference terms, a glossary is built (O2) and the semantic mismatches identified in the process are recorded for future mappings aid (O1).
303
- Ontologies Mapping: In this final step, mapping tables (O6) are created, describing the relationships between the reference ontology and the ontologies from all the participants, or other respective knowledge representation models. For this matter, the methodology uses an auxiliary ontology, named Mediator, which records the mapping establishments enabling its subsequent reasoning (Gaspar, 2011). The mediator has the main role on the translation from one message format to another allowing the communication between two different systems. To put it into perspective, Fig.3 illustrates the communication between two enterprises with the mediator in the middle. The Mediator ontology proposed by Agostinho et al. in (Agostinho et al., 2011) is able to represent any model structure and its related elements, plus morphism (mappings and transformations) in a way that enables keeping track of the inner-elements relationships with its participant owner. Thus, it maintains a traceable record of such mappings to support intelligence activities such as ontology learning features and specific composition of transformations.
Fig. 2. MENTOR Methodology (Sarraipa et al. 2010b) - Thesaurus Building: In the final step of the first phase, a taxonomic structure is manually defined. The participants have a voting process to hierarchically classify every single term in the defined glossary. When this process is finished, a thesaurus is defined (O3) and the methodology advances to the second phase.
Fig. 3. Data Exchange with the Mediator Ontology Aid
The second phase or Reference Ontology Building Phase is where a reference ontology is built. Similarly to the first phase, three steps constitute the second phase (Sarraipa et al., 2008):
When the MENTOR methodology is used for the first time, there are no mappings between each of the enterprise models. Consequently, it is needed to represent all the ontologies or knowledge representation models that participated in the reference ontology building, plus the reference one, in the mediator ontology. Only after that procedure, mappings between the various model elements can be represented. With such mapping relations, when one participant’s system communicates with another that do not shares internally the same semantics, a transformation request is sent to the mediator component. The mediator is then able to transform that request message into the destination partner format and lexicon to deliver it accordingly to its semantics.
- Ontology Gathering: Here the methodology gathers the knowledge representation models or ontologies from which the terms came form. - Ontology Harmonization: In this step the structure of the reference ontology is discussed, taking into account the structure of the previously defined thesaurus, plus the ones from the gathered knowledge representation models. If an agreement is reached, then the taxonomy structure of the reference model is established (O4) and the second cycle of this step begins. The second cycle is a similar harmonization step, but this time, instead of harmonizing the taxonomic relationships, a content harmonization takes place, resulting on a reference ontology by the end of this step (O5).
3.1 Lexicon Settlement from Fact Models
324
May 11-13, 2015. Ottawa, Canada 304
Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307
Fig. 4. Reference Enterprise Lexicon Tool Architecture For the construction of a methodological approach for building a domain reference lexicon from fact models, some adaptations to the first three original steps of the MENTOR methodology were carried out. One of the main purposes of such adaptation was to enable the use of business knowledge based on Fact Models instead of ontologies. Thus, the first step in this methodology adaptation consists in the extraction of its concepts from the Fact Models of a pre-determined domain and community. For that matter, the authors used Visual Studio’s NORMA tool, as it allows the construction of a formal and conceptual model and the posterior data extraction by programmatically manipulating each model elements with the aid of its NORMA’s API.
With all the concepts extracted, a 2-phases semantic mismatch detection process takes place. Whenever the user selects one of the extracted terms, the developed algorithm must search for possible synonyms that might be considered mismatches. This process uses an auxiliary myThes tool, provided by the NHunspell API. If the algorithm detects possible semantic mismatches, the users must then choose the term that they find most appropriate and that will be part of the domain reference lexicon. During this process of choosing the reference term and respective description, a list of the semantic mismatch records is established, providing a link between the enterprise’s proprietary terms and the reference term. These semantic mismatches are passed and stored in the Mediator Ontology. With all the reference terms and respective descriptions chosen, a glossary is built and stored in a database.
After gathering all the involved terms and relationships from the Fact Models starts the glossary definition process. Knowing that a glossary consists basically on an ordered list of terms with the respective descriptions, it is possible to use the conceptual characteristics of the Fact Models, filling the glossary file with each of the involved terms. To extract the definitions of each term, we can rely on the fact types and constraints presented in the Fact Model or proprietary note descriptions given by each enterprise. For instance, if we were to extract information from the simple predicate expression presented in Fig.1 example, then we would get information that defines the terms Person and Age. This information includes their term type, note descriptions and every single constraint that define their relationships (in this case, mandatory and internal uniqueness constraints).
With a glossary built, the methodology goes forward to the next step, where all the terms are categorized into a hierarchical structure, a taxonomy. This taxonomy, if complemented with its concepts meanings descriptions becomes a thesaurus. Since we are talking about hierarchical structures, we must take into account that taxonomies follow the relations “is-a” type to each of its involved terms. However, in this approach it was added the possibility of generating other faceted classifications. Faceted classification is an analytic-synthetic classification scheme, which allows other types of relations based on the 325
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
facet chosen. For instance, if we were using a fact model that included the fact types “Car has Colour”, “Employee drives Car” and “Car has Model” then the faceted classification generated using the type “has” would have a father node “Car” and two children nodes “Colour” and “Model”.
305
case is Fact Models. Fig.5 and Fig.6 illustrate the contributed Fact Models for this simple demonstration from enterprise A and B respectively.
4. CASE STUDY To develop a prototype of the approach defined for building a reference lexicon, the authors came up with a concise architecture, using the tools and services illustrated in the Fig.4. This architecture is composed by 5 main components: the MENTOR User Interface where the Fact Models are gathered and managed; the Project/User Data Base used to manage the user information and the projects that these users took part; the Mismatch Mediator DB used to store the mismatches obtained on the Glossary Building Step; the mediator ontology (developed in the Java Eclipse environment), which uses the Protégé OWL API for storing and reasoning the mapping relations between the reference and the proprietary fact models concepts using an ontology conceptualization format (OWL). For the demonstration of the developed approach, a practical example about an enterprise environment is presented. This example represents and structures business knowledge about some simple business concepts used to characterize the registration process of the enterprise employees and their respective personal information as the “cars” used by them, in their companies.
Fig. 6. Fact Model 2 provided by the enterprise B The first Fact Model (from enterprise A) contains 4 entity types, terms that are connected to a value identifier, the reference scheme and 8 value types, constant value terms. To keep this experimentation simple, the authors decided to only include simple constraints, such as, mandatory constraints, the constraints that are used to define the absolute essential fact types necessary for the business domain to function properly, and uniqueness constraints, used to define the kind of multiplicity shared by each of the fact types. Once through the developed prototype, the analyse of the Fact Model ORM files starts, to initiate the glossary building, the system, with the NORMA API libraries support, extracts all the terms and fact types that form the models. Then the system merges all the terms in a single list of terms and all the fact types in a single fact type list. Subsequently, the system fills dynamically the combo boxes with all the terms and fact types as required. After this, users can review the data that was extracted. As an example, by selecting one of the terms as “Car” (see Fig.7), all the information related to this term, which includes, term’s type, reference scheme, fact types associated to and possible note descriptions are revealed. In this case the system detects the synonym “Automobile” and displays three possible descriptions, a note description of the term “Car” (Fact Model 1), a description based on fact types of the term “Car” (Fact Model 1) and a description based on fact types of the term “Automobile” (Fact Model 2). Then, the poll decides which will be the term that will be part of the reference lexicon, or even define another. After click the “Define Reference” button,
Fig. 5. Fact Model 1 provided by the enterprise A After connected to the prototype user interface each enterprise representative or contributor must upload his/her enterprise business domain structure, which in this 326
INCOM 2015 11-13, 2015. Ottawa, Canada Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307
May 306
Fig. 7. Reference Enterprise Lexicon Establishment
Fig. 8. Reference Fact Model defined and a faceted classification of “has” type
illustrated in the right picture of Fig. 8. This shows a “has” facet classification kind.
the chosen term and description are defined as reference and are added to the glossary. The identified mismatches of the terms are recorded in mediator.
5. CONCLUSIONS AND FUTURE WORK The present prototype only accomplishes the first phase of the MENTOR methodology (Lexicon Settlement). However, to test MENTOR implementation feasibility in relation to fact models, even manually, this case study performed all the MENTOR steps. As a result it was defined the reference Fact Model shown in left part of Fig.8. In addition to the Lexicon defined it was also tested the faceted classification feature as
In this paper an approach to define a reference lexicon from fact models based in the MENTOR methodology is proposed. The approach performs an adaptation of MENTOR, including the integration of a faceted classification functionality, which by accomplishing some automatized features facilitate the generation of a reference thesaurus. This will enable 327
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
enterprises that use fact models to establish semantic agreements and a reference fact model within their business network to facilitate interoperable communication between their stakeholders’ systems.
307
Halpin, T. (2001). “Object-Role Modeling : an overview,” Retrieved from the web at October 2014: http://www.orm.net/pdf/ORMwhitePaper.pdf. Halpin, T. (2014). “Object Role Modeling - The Official Site for Conceptual Data Modeling”. Retrieved from the web at October 2014: http://www.orm.net/. Halpin, T. and Bloesch, A. (1998). A comparison of UML and ORM for data modelling. In Proceedings of the 3th CAISE/IFIP-WG8.1 International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design. Holsapple, C. W.; Joshi, K. D.; (2002). “A Collaborative Approach to Ontology Design”. In: Communications of the ACM, ISSN: 0001-0782, Vol. 45, pp. 42-47, 2002. Lenci, A. (2002). “Building an Ontology for the Lexicon: Semantic Types and Word Meaning,” [Jensen and Skadhauge (eds.) 01], pp. 103 -120, [http://www.ontoquery.dk/publications/docs/Building_an _Ontology.doc ], 27 November 2002. Lin, H. N.; Tseng, S. S.; Weng, J. F.; Lin, H. Y.; Su, J. M.; (2007). “An Iterative, Collaborative Ontology Construction Scheme”. In: Second International Conference on Innovative Computing, Information and Control (ICICIC 2007), ISBN: 0-7695-2882-1, pp. 150, 2007. ModernAnalist.com (2012). Interview Questions for Business Analysts and Systems Analysts – What is a Fact Model?. Retrieved from the web at March 2015: http://www.modernanalyst.com/Careers/InterviewQuesti ons/tabid/128/ID/1537/What-is-a-Fact-Model.aspx NeOn Project, 2010. Accessed at August 2014: http://www.neon-toolkit.org/wiki/Main_Page Purchase, J., (2010). What is a Fact Model? Why Should You Have One?. Retrieved from the web at October 2014: http://blog.luxmagi.com/2010/04/what-is-a-fact-modelwhy-should-you-have-one/, 2010. Ross, G. R. (2000). What Are Fact Models and Why Do You Need Them (Part 1). Retrieved from the web at March 2015: http://www.brcommunity.com/b008a.php Sarraipa, J., Jardim-Goncalves, R., Gaspar, T., and A. Steiger-Garcao, A. (2010). “Collaborative ontology building using qualitative information collection methods”. In Proceedings of 5th IEEE Int. Conf. Intell. Syst., pp. 61–66, Jul. 2010. Sarraipa, J., Jardim-Goncalves, R., and Steiger-Garcao, A. (2010). “MENTOR: an enabler for interoperable intelligent systems,” Int. J. Gen. Syst., vol. 39, no. 5, pp. 557–573, Jul. 2010. Sarraipa, J., Silva, J. P. M. A., Jardim-Goncalves, R., and Monteiro, A. A. C. (2008). “MENTOR – A Methodology for Enterprise Reference Ontology Development”. In: Intelligent Systems, 2008. In Proceedings of IS '08. 4th International IEEE Conference, Vol. I, 6-8 Sept. 2008. Tudorache, T (2015). Retrieved from the web at 01/2015: http://protegewiki.stanford.edu/wiki/Collaborative_Prote ge Vernadat, F.B. (1997). Enterprise Modelling Languages ICEIMT'97 Enterprise Integration - International Consensus. EI-IC ESPRIT Project 21.859.
For future work, it will be studied more extensively all the available constraints and characteristics of the fact models, taking advantage of them when generating the reference lexicon, but on the other hand also analysing its representation feasibility in the mediator ontology. It would be equally important to accomplish the prototype with all the MENTOR phases procedures handling fact models, which will enable the capability of handling models of multiple types (both Fact Models and Ontologies), in a same approach, and build a reference lexicon between those multiple types. Finally, it will be more explored the faceted classification functionality to build various conceptual structures of the same knowledge model. This integrated with the nature of Fact Models that facilitate models verbalization in sentences will enable the use of natural language processing to automatize the procedure. This should improve the overall and formal understanding of an enterprise business model, which could potentiate the definition of enhanced and dynamic semantic issues resolutions. 5. AKNOWLEDGEMENTS The research leading to these results have received funding from the European Union H2020-FoF-2014 Framework Programme under the grant agreement of the project: Cloud Collaborative Manufacturing Networks (C2NET) nr 636909, which will continue this line of research. REFERENCES Agostinho, C.; Sarraipa, J.; Goncalves, D.; and JardimGoncalves, R. (2011). “Tuple-Based Semantic and Structural Mapping for a Sustainable Interoperability,” in 2nd Doctoral Conference on Computing, Electrical and Industrial Systems (DOCEIS’11), 2011. Ambler, S. (2015). Enterprise Agile: Business Modeling. Retrieved from the web at March 2015: http://www.enterpriseunifiedprocess.com/essays/enterpri seBusinessModeling.html Auer, S.; Dietzold, S.; Riechert, T. (2006). “OntoWiki – A Tool for Social, Semantic Collaboration”. In Proceedings of the 5th international conference on The Semantic Web (ISWC'06). ISBN: 978-3- 540-49029-6, pp 736 - 749, (2006). Dietzold, S. (2011). OntoWiki. Retrieved from the wb at August 2011: http://ontowiki.net/Projects/OntoWiki Fact Based Modeling WG, (2011). “What is Fact Based Modeling” Retrieved from the web at October 2014: http://www.factbasedmodeling.org/. Gaspar, T. (2011). “Methodology for Collaborative Enterprise Reference Ontology Building,” FCT-DEE MSc Thesis, 2011. Retrieved from the web at October 2014: http://hdl.handle.net/10362/5708. Halpin, T. (1989). ‘A Logical Analysis of Information Systems: static aspects of the data-oriented perspective’, PhD thesis, University of Queensland. 328
ScienceDirect
IFAC-PapersOnLine 48-3 (2015) 300–307
A Reference Reference Lexicon Lexicon Definition Definition from from Fact Fact Models Models A A Reference Lexicon Definition from Fact Models Pedro Andrade*. Andrade*. Joao Joao Sarraipa* Sarraipa* Pedro Ricardo Jardim-Goncalves* Ricardo Jardim-Goncalves* Pedro Andrade*. Joao Sarraipa* Ricardo Jardim-Goncalves*
*CTS, *CTS, UNINOVA, UNINOVA, Dep.º Dep.º de de Eng.º Eng.º Electrotécnica, Electrotécnica, Faculdade Faculdade de de Ciências Ciências ee Tecnologia, Tecnologia, FCT, FCT, Universidade Universidade Nova Nova de de Lisboa, Lisboa, 2829-516 Caparica, Portugal; (e-mail: [email protected]; [email protected]; [email protected]). 2829-516 Caparica, Portugal; (e-mail: [email protected]; [email protected]). *CTS, UNINOVA, Dep.º de Eng.º Electrotécnica, Faculdade de Ciê[email protected]; e Tecnologia, FCT, Universidade Nova de Lisboa, 2829-516 Caparica, Portugal; (e-mail: [email protected]; [email protected]; [email protected]). Abstract: Nowadays, Nowadays, it it has has been been noticed noticed an an increased increased demand demand for for interoperable interoperable systems systems capable capable of of Abstract: exchangingNowadays, information within collaborative businessdemand environments. Consequently, cooperation exchanging information within business environments. Consequently, Abstract: it has been collaborative noticed an increased for interoperable systems cooperation capable of agreements between between each of ofwithin the involved involved enterprises have been been brought to to light. light. However, due duecooperation to the the fact fact agreements each the enterprises have brought However, to exchanging information collaborative business environments. Consequently, that even in a same community or domain, there are a big variety of business concept models that are not that even in between a same community domain,enterprises there are ahave big variety of business concept models arefact not agreements each of theor involved been brought to light. However, duethat to the semantically coincident, which embodies the need of an enterprise reference lexicon definition for semantically whichorembodies the need enterprise reference lexicon definition for that even in a coincident, same community domain, there are a of bigan variety of business concept models that are not interoperable communications establishment. This paper proposes an approach that addresses the interoperable communications approach that addresses semantically coincident, which establishment. embodies the This need paper of an proposes enterprise an reference lexicon definition the for automation in in communications the information information models models mappingThis and the the reference lexicon construction. Itaddresses aggregatestheaa automation the mapping and reference lexicon construction. aggregates interoperable establishment. paper proposes an approach that It formal and and conceptual conceptual representation ofmapping the business business domain, with lexicon clear definition definition of the the used lexicon lexicona formal representation the domain, with aa clear of used automation in the information modelsof and the reference construction. It aggregates to facilitate a further and overall understanding of the business model. to facilitate a further andrepresentation overall understanding of the business formal and conceptual of the business domain, model. with a clear definition of the used lexicon to a further and overall understanding ofIntegration; theControl) business model. © facilitate 2015, IFAC (International Federation of Automatic Hosting by Elsevier Ltd. All Representation. rights reserved. Keywords: Enterprise Interoperability; Semantic Data Models, Knowledge Keywords: Enterprise Interoperability; Semantic Integration; Data Models, Knowledge Representation. Keywords: Enterprise Interoperability; Semantic Integration; Data Models, Knowledge Representation.
1. 1. INTRODUCTION INTRODUCTION 1. INTRODUCTION The The globalization globalization of of the the business business market market is is aa reality reality that that we we face at the present day. Although the positive effects that face at the present of day. positive this The globalization theAlthough business the market is a effects reality that that this we phenomena has to as direct phenomena has provided provided to the thethecommunity, community, as aathat direct face at the present day. Although positive effects this consequence or after small consequence or provided after effect effect of this, small and and medium phenomena has to of the this, community, as amedium direct enterprises (SME) have found themselves to be enterprises haveeffect foundofthemselves to be inevitably consequence(SME) or after this, small andinevitably medium choked by industry’s so “big order choked by the the industry’s so called called “big fishes”. fishes”. Ininevitably order for for enterprises (SME) have found themselves to beIn those SME enterprises to keep in business and to maintain those SME enterprises to keep in business and to maintain choked by the industry’s so called “big fishes”. In order for their they increase their and their credibility, they must must increase their competitiveness competitiveness and thosecredibility, SME enterprises to keep in business and to maintain productivity, which aa greater efficiency productivity, which requires greater efficiency on on their their their credibility, they requires must increase their competitiveness and processes and management. Thus, it has been realized by processes andwhich management. it hasefficiency been realized by productivity, requires Thus, a greater on their these enterprises that success would only come through the these enterprises that success Thus, woulditonly processes and management. has come been through realized the by establishment of each establishment of cooperation cooperation agreements among each other. other. these enterprises that success agreements would onlyamong come through the However, due to worldwide diversity the However, due of to the the worldwide diversity of ofamong the communities, communities, establishment cooperation agreements each other. aaHowever, high number of knowledge representation elements, such high number of the knowledge representation such as as due to worldwide diversity of elements, the communities, business concept models and ontologies, which are not business concept models and ontologies, which are a high number of knowledge representation elements, suchnot as semantically coincident, have appeared representing semantically coincident, have appeared representing the same business concept models and ontologies, which the aresame not segment of (Sarraipa al., a). segment of reality reality (Sarraipa etappeared al., 2010 2010 representing a). As As aa consequence consequence semantically coincident, haveet the same of that, enterprises have faced many problems trying of that, enterprises have faced problems when trying to to segment of reality (Sarraipa et many al., 2010 a). As when a consequence communicate with each other, since most likely none of communicate with each since most likelywhen nonetrying of their their of that, enterprises have other, faced many problems to systems or uses the to their systems or actors actors uses other, the same same lexicon to represent represent communicate with each sincelexicon most likely none of their domain domain ofordiscourse. discourse. systems of actors uses the same lexicon to represent their domain of discourse. To To contribute contribute to to solve solve this this interoperability interoperability issue, issue, the the authors authors propose an approach for the establishment of an enterprise propose an approach for the establishment of an enterprise To contribute to solve this interoperability issue, the authors reference from concept reference lexicon fromforbusiness business concept models, models, addressing propose anlexicon approach the establishment of an addressing enterprise the the models mapping for the automation automation infrom the information information models mapping for the the reference lexiconin business concept models, addressing reference lexicon construction. This approach aggregates reference lexicon Thismodels approach aggregates the automation in construction. the information mapping for theaa formal and conceptual representation the domain formal andlexicon conceptual representation of the business business domaina reference construction. This of approach aggregates and gives a clear definition of the used lexicon to facilitate an and gives clear definition of the usedoflexicon to facilitate an formal anda conceptual representation the business domain overall understanding by all the involved stakeholders (e.g. overall understanding by all stakeholders (e.g. and gives a clear definition of the the involved used lexicon to facilitate an modellers), including (Information Technology) modellers), including bynon-IT non-IT (Information Technology) overall understanding all the involved stakeholders (e.g. personnel. personnel. modellers), including non-IT (Information Technology) personnel.
Consequently, Consequently, to to introduce introduce such such proposed proposed approach, approach, the the paper first presents the type of business concept model paper first presents the typesuch of business model Consequently, to introduce proposed concept approach, the addressed this also the some addressed bypresents this research research also with with the clarification clarification ofmodel some paper firstby the type of business conceptof of its concepts. Then proposed reference lexicon of its related related concepts. Then the proposed reference of lexicon addressed by this research alsothe with the clarification some establishment approach from fact models is explained. establishment approachThen fromthefact models is explained. of its related concepts. proposed reference lexicon Afterwards, architecture aa prototype on Afterwards, theapproach architecture of fact prototype based on the the establishmentthe fromof models based is explained. approach defined plus a use case demonstration is described. approach defined plus a use case is described. Afterwards, the architecture of demonstration a prototype based on the Finally some some conclusions with future steps on on this this research Finally conclusions steps research approach defined plus a usewith casefuture demonstration is described. work are presented. work aresome presented. Finally conclusions with future steps on this research work are presented. 2. 2. USING USING FACT FACT MODELS MODELS FOR FOR CONCEPTS CONCEPTS EXTRACTION EXTRACTION 2. USING FACT MODELS FOR CONCEPTS EXTRACTION Nowadays, Nowadays, enterprises enterprises are are embracing embracing the the ICT ICT (Information (Information and Communications Technology) era, which has and Communications has pushed pushed Nowadays, enterprises Technology) are embracingera, thewhich ICT (Information them for the integration of Enterprise Modelling (EM) related themCommunications for the integrationTechnology) of Enterprise era, Modelling related and which (EM) has pushed systems or solutions to support the enhancement of their systems or solutions theModelling enhancement their them for the integrationtoofsupport Enterprise (EM)ofrelated business activities. This is in line with Ambler statement business activities. This is in line with Ambler statement systems or solutions to support the enhancement of their about EM (Ambler, 2015), which even seeming about EMactivities. (Ambler,This 2015), which says that evenstatement seeming business is in line says with that Ambler superfluous, formally documenting the business that superfluous, formally2015), documenting the that business that an an about EM (Ambler, which says even seeming organization engages in will lead to many interesting organization engages documenting in will lead the to business many interesting superfluous, formally that an conversations about should and, conversations about how how things should really work and, organization engages in things will lead to really many work interesting ultimately, to a shared understanding of exactly what ultimately, a shared of exactly conversationsto about how understanding things should really work what and, business the enterprise are and the business the to enterprise are in inunderstanding and how how it it execute execute the work. work. ultimately, a shared of exactly what business the enterprise are in and howmore it execute the work. Thus, Thus, it it could could be be said said that that to to be be more efficient efficient an an ICT ICT enterprise needs to model its business to assure advanced enterprise needs to model its business to assure advanced Thus, it could be said that to be more efficient an ICT functionalities in its systems. is process building functionalities in to its model systems. EM is the the to process ofadvanced building enterprise needs itsEM business assureof models of whole or part of an enterprise with business models of whole part ofEM an isenterprise with functionalities in itsorsystems. the process of business building models, models, data resource models and models, process process models, dataofmodels, models, resource with models and or or models of whole or part an enterprise business new ontologies etc. (Vernadat, 1997). A business model new ontologies (Vernadat, 1997).resource A business model can models, process etc. models, data models, models andcan or be as top-level model that the be defined as aa etc. top-level model1997). that defines defines the enterprise’s enterprise’s newdefined ontologies (Vernadat, A business model can strategic which all the others derive. strategic plan, from which all that the defines others models models derive. be definedplan, as a from top-level model the enterprise’s Among the various models, there is the business entity model Among various models, business entityderive. model strategicthe plan, from whichthere all is thetheothers models type or Fact Model, which structures business knowledge type or Fact Model, which structures business knowledge Among the various models, there is the business entity model type or Fact Model, which structures business knowledge
2405-8963 © 2015, IFAC (International Federation of Automatic Control) Hosting by Elsevier Ltd. All rights reserved. Peer review under responsibility of International Federation of Automatic Control. Copyright 321 Copyright © © 2015 2015 IFAC IFAC 321 10.1016/j.ifacol.2015.06.098 Copyright © 2015 IFAC 321
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
301
2.1 ORM 2 – Object Role Modelling
about core business concepts and business operations (ModernAnalist.com, 2012).
Object Role Modelling is a fact-oriented data modelling technique proposed by Terry Halpin in 1989 (Halpin, 1989) (Halpin and Bloesch, 1998) for performing information analysis at the conceptual level, where the application is described in terms easily understood by non-technical users. In practice, ORM data models often capture more business rules, and are easier to validate and evolve than data models in other approaches (Halpin, 2014). Unlike the EntityRelationship (ER) modelling and Unified Modelling Language (UML) class diagrams, fact-oriented modelling is attribute-free, treating all elementary facts as relationships, which facilitate verbalization in sentences and highlight connectedness through semantic domains.
This paper focuses on the situation of enterprises collaboration and cross-organizational business processes establishment, which requires systems with seamless interoperable communications. Since, a good Fact Model tells you how to structure your basic thinking (or "knowledge") about the business process based on a standard vocabulary (Ross, 2000), it is requisite to address a case of having enterprises’ fact models acting as inputs of a reference lexicon definition for the establishment of semantic agreements between organisations. A Fact Model is a business-oriented representation of the domain key concepts (Purchase, 2010). This kind of models must include all the structure of the company, describing how the company creates, delivers and captures value. Additionally, they have the goal of structuring the essential knowledge about business operations in a more user-friendly way, using standard vocabulary and thus allowing the expression of each element of the business terminology in a design-independent fashion, making it possible for non-IT stakeholders to participate more actively on the development. To help ensure correctness, clarity, adaptability and productivity, information systems are best specified first at the conceptual level, using concepts and language that people can readily understand (Halpin, 2001).
This method simplifies the design process by using CNL, as well as intuitive diagrams, which can be populated with examples, and by examining the information in terms of elementary facts, that are named, atomic fact (Halpin, 2001). By expressing the model in terms of natural concepts, like objects and roles, it provides a conceptual approach for modelling. Object Role Modelling views the world as a set of objects (entities and values) that play roles (their parts in each relationship). These are the most elementary elements of the ORM conceptual schema.
Consequently, if these indications are followed all the business stakeholders will naturally accept and understand the language used to define the vocabulary of such formal business representations. In this sense, a Fact Model can be a starting point for developing the next steps of business knowledge, as constraints and rules. This type of model focuses on logical basic connections (called Fact Types) between core concepts (represented by Terms) of the business in an intuitive manner. Besides the fact that businesses are runing on rules, fact types bring lots of benefits, making the visualization of all the business concepts very intuitive, even for non-IT personnel.
Fig. 1. Simple predicate expression with ORM. As it is possible to verify in this small ORM scheme, Person is an object type and is illustrated as a continuous line rectangle, having a reference scheme “(.name)”. This means that a Person is identified by its name. The term depicted as a dashed rectangle is a value type and the middle rectangle is the predicate that connects the two terms. In this case, there are two rectangles, as there are two different roles represented (binary fact type), one for each direction of read. The defined fact types of this simple example are: “Person has Age” from left to right, and “Age is of Person” from right to left.
In order to understand the difference between a fact type and a rule in a more clear way, if we were to pick for instance, the fact type “customer places order” and then extend it to “customer places at least one order”, then we would be adding a constraint to the fact type and thus, creating a rule.
The bar over the first role is used to define an internal uniqueness constraint. These constraints declare that instances for that role in the fact type population must be unique. With that said, it means that, for instance, in Fig.1, the constraint on the “has” predicate verbalize that a Person cannot have more than one Age value but that it is possible for the same Age to be given to more than one Person.
Fact based modelling has been researched and applied in business of semantic modelling for information systems since the 70s as a way to model, query and transform facts using attribute-free structures based on Constrained Natural Language (CNL). Subsequently, several developments have taken place in parallel, resulting in several fact based modelling “dialects”, including NIAM, ORM2, DOGMA and FCO_IM (Fact Based Modeling WG, 2011). The authors made a short comparison between each of these languages and due to the existence of an API accomplished by an active support community the authors decided to focus their analysis and prototype development in ORM2 language.
Finally, to finish this example, the dot placed on the “has” predicate is a mandatory role constraint. What that constraint does is to define that each Person needs to have some Age value. It is a relationship that needs to exist in order for the business model to function properly.
322
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
302
These are the most basic functionalities of the ORM language. Of course, ORM has a very vast list of possible constraints to be used.
2015). Furthermore, it allows other operations such as track changes, chat, comments on ontology changes, voting, etc. The OntoWiki tool is a collaborative environment that supports the visual presentation of an ontology as an information map, with different views on instance data (Auer et al., 2006). It uses particular functionalities as: Change tracking, Commenting, Rating, Popularity and Activity/Provenance. Additionally, it enables intuitive authoring of semantic content, with an inline-editing mode for editing RDF content, similar to WYSIWYG (What You See Is What You Get) for text documents (Dietzold, 2011).
3. ESTABLISHING A REFERENCE LEXICON The definition of a reference lexicon has the main objective of establishing a set of concepts with shared meanings to be representative of a certain domain and community. Then such community systems or actors can use them in business descriptions facilitating the semantic interoperability establishment. However, due to a natural behaviour of a system, such lexicon shouldn’t be considered fixed, thus it should be passible of modifications on its lifetime requiring semantic adaptations capabilities.
The NeOn methodology has the main objective of improving the capability to handle multiple networked ontologies that are created collaboratively, and might be highly dynamic and constantly evolving (NeOn Project, 2010). This methodology integrates a set of different building ontology scenarios accomplished with documented procedures to guide users developing their ontologies using the NeOn Toolkit.
Additionally to the reference lexicon establishment, some common standards as: Standard for the Exchange of Product model data (STEP), or OWL (Web Ontology Language) could be used. Thus, apart of using a standard to formalise a product, a process or a message, the lexicon mentioned still being necessary to represent such standards specific elements as naming and descriptions (contents) ensuring their common understanding.
It was identified that from all the presented methodologies NeOn methodology and its associated tool is the one that addresses all the mentioned requirements, but without aggregating all the mentioned characteristics in a methodology as an all. It does not fulfil the process of supporting enterprises to establish a common view on their semantics, establishing at the same time mappings tables of the reached semantic agreements. Thus, the communications between old semantic and new semantic systems are not facilitated neither its translations nor transformations. From this, it was identified the necessity of having a methodology focused on supporting the building of a reference ontology able to represent all the actors semantics, but at the same time that could let enterprises still work with their traditional and old semantics.
Ontologies are widely used as formal devices to represent the lexical content of words (Lenci, 2002). Aligned to this, authors proposed the definition of a reference lexicon through an ontology building methodology. Thus, also based on the previous statements, it was identified some requirements to which such methodology should answer to. It should support the ontology collaborative building enriched with Qualitative Information Collection Methods (QICM) to support collaborative definitions and decisions. Additionally, such methodology should be able to facilitate the ontology building from scratch and by reengineering of existent ones. The collaborative building of ontologies uses merging or integration functionalities supported by the establishment of mappings between existent ontologies and the new built one, enabling the traceability of the knowledge evolution allowing keep in use old semantic representations if needed. Based on these requirements it was identified some collaborative ontology building tools and methodologies presented in the following.
Consequently, MENTOR (Methodology for Enterprise Reference Ontology Development) was the methodology chosen. It is a methodology that allows the construction of a reference ontology of in a collaborative environment, enabling all the involved stakeholders to share their knowledge and combine it in order to come to an agreement about all the terms and relations that will be included in the business domain (Sarraipa et al., 2008). MENTOR also operates as an intermediate between each of the source data models, allowing the involved stakeholders to maintain their own business models.
The Iterative Collaborative Ontology Construction (ICOC) scheme, supports the online collaborative knowledge contribution by using a wiki-like application supported by a Delphi-like method to converge the answers to an automatic generated questionnaire to construct a uniform ontology (Lin et al., 2007).
The MENTOR methodology is composed by two phases that have three steps each. A diagram of this methodology is presented in Fig.2. The first phase of this methodology, named Lexicon Settlement Phase, consists on the knowledge acquisition phase. This phase is comprised by the following steps (Sarraipa et al., 2008):
Holsapple and Joshi in (Holsapple and Joshi, 2002) also uses a Delphi-like method in four phases to structure collaborative discussions to reach consensus, demonstrating the ontology use at its ending phase.
- Terminology Gathering: In this first step, MENTOR receives all the relevant and necessary terms from all the involved stakeholders and tags each term with the name of the respective contributor.
Collaborative Protégé is an extension of the existing Protégé tool to support collaborative ontology editing, where the changes made by a user are reflected on the repository, enabling other users see the changes on the fly (Tudorache,
- Glossary Building: In this step, MENTOR requests a description of each of the previously added terms. After 323
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
having each of the participants manually providing this information, a voting process takes place. In this process, each participant review the descriptions uploaded by all other participants and choose the one that seems the most proper. At the end of this process, if all the stakeholders came to an agreement, the chosen terms are defined as reference terms, a glossary is built (O2) and the semantic mismatches identified in the process are recorded for future mappings aid (O1).
303
- Ontologies Mapping: In this final step, mapping tables (O6) are created, describing the relationships between the reference ontology and the ontologies from all the participants, or other respective knowledge representation models. For this matter, the methodology uses an auxiliary ontology, named Mediator, which records the mapping establishments enabling its subsequent reasoning (Gaspar, 2011). The mediator has the main role on the translation from one message format to another allowing the communication between two different systems. To put it into perspective, Fig.3 illustrates the communication between two enterprises with the mediator in the middle. The Mediator ontology proposed by Agostinho et al. in (Agostinho et al., 2011) is able to represent any model structure and its related elements, plus morphism (mappings and transformations) in a way that enables keeping track of the inner-elements relationships with its participant owner. Thus, it maintains a traceable record of such mappings to support intelligence activities such as ontology learning features and specific composition of transformations.
Fig. 2. MENTOR Methodology (Sarraipa et al. 2010b) - Thesaurus Building: In the final step of the first phase, a taxonomic structure is manually defined. The participants have a voting process to hierarchically classify every single term in the defined glossary. When this process is finished, a thesaurus is defined (O3) and the methodology advances to the second phase.
Fig. 3. Data Exchange with the Mediator Ontology Aid
The second phase or Reference Ontology Building Phase is where a reference ontology is built. Similarly to the first phase, three steps constitute the second phase (Sarraipa et al., 2008):
When the MENTOR methodology is used for the first time, there are no mappings between each of the enterprise models. Consequently, it is needed to represent all the ontologies or knowledge representation models that participated in the reference ontology building, plus the reference one, in the mediator ontology. Only after that procedure, mappings between the various model elements can be represented. With such mapping relations, when one participant’s system communicates with another that do not shares internally the same semantics, a transformation request is sent to the mediator component. The mediator is then able to transform that request message into the destination partner format and lexicon to deliver it accordingly to its semantics.
- Ontology Gathering: Here the methodology gathers the knowledge representation models or ontologies from which the terms came form. - Ontology Harmonization: In this step the structure of the reference ontology is discussed, taking into account the structure of the previously defined thesaurus, plus the ones from the gathered knowledge representation models. If an agreement is reached, then the taxonomy structure of the reference model is established (O4) and the second cycle of this step begins. The second cycle is a similar harmonization step, but this time, instead of harmonizing the taxonomic relationships, a content harmonization takes place, resulting on a reference ontology by the end of this step (O5).
3.1 Lexicon Settlement from Fact Models
324
May 11-13, 2015. Ottawa, Canada 304
Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307
Fig. 4. Reference Enterprise Lexicon Tool Architecture For the construction of a methodological approach for building a domain reference lexicon from fact models, some adaptations to the first three original steps of the MENTOR methodology were carried out. One of the main purposes of such adaptation was to enable the use of business knowledge based on Fact Models instead of ontologies. Thus, the first step in this methodology adaptation consists in the extraction of its concepts from the Fact Models of a pre-determined domain and community. For that matter, the authors used Visual Studio’s NORMA tool, as it allows the construction of a formal and conceptual model and the posterior data extraction by programmatically manipulating each model elements with the aid of its NORMA’s API.
With all the concepts extracted, a 2-phases semantic mismatch detection process takes place. Whenever the user selects one of the extracted terms, the developed algorithm must search for possible synonyms that might be considered mismatches. This process uses an auxiliary myThes tool, provided by the NHunspell API. If the algorithm detects possible semantic mismatches, the users must then choose the term that they find most appropriate and that will be part of the domain reference lexicon. During this process of choosing the reference term and respective description, a list of the semantic mismatch records is established, providing a link between the enterprise’s proprietary terms and the reference term. These semantic mismatches are passed and stored in the Mediator Ontology. With all the reference terms and respective descriptions chosen, a glossary is built and stored in a database.
After gathering all the involved terms and relationships from the Fact Models starts the glossary definition process. Knowing that a glossary consists basically on an ordered list of terms with the respective descriptions, it is possible to use the conceptual characteristics of the Fact Models, filling the glossary file with each of the involved terms. To extract the definitions of each term, we can rely on the fact types and constraints presented in the Fact Model or proprietary note descriptions given by each enterprise. For instance, if we were to extract information from the simple predicate expression presented in Fig.1 example, then we would get information that defines the terms Person and Age. This information includes their term type, note descriptions and every single constraint that define their relationships (in this case, mandatory and internal uniqueness constraints).
With a glossary built, the methodology goes forward to the next step, where all the terms are categorized into a hierarchical structure, a taxonomy. This taxonomy, if complemented with its concepts meanings descriptions becomes a thesaurus. Since we are talking about hierarchical structures, we must take into account that taxonomies follow the relations “is-a” type to each of its involved terms. However, in this approach it was added the possibility of generating other faceted classifications. Faceted classification is an analytic-synthetic classification scheme, which allows other types of relations based on the 325
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
facet chosen. For instance, if we were using a fact model that included the fact types “Car has Colour”, “Employee drives Car” and “Car has Model” then the faceted classification generated using the type “has” would have a father node “Car” and two children nodes “Colour” and “Model”.
305
case is Fact Models. Fig.5 and Fig.6 illustrate the contributed Fact Models for this simple demonstration from enterprise A and B respectively.
4. CASE STUDY To develop a prototype of the approach defined for building a reference lexicon, the authors came up with a concise architecture, using the tools and services illustrated in the Fig.4. This architecture is composed by 5 main components: the MENTOR User Interface where the Fact Models are gathered and managed; the Project/User Data Base used to manage the user information and the projects that these users took part; the Mismatch Mediator DB used to store the mismatches obtained on the Glossary Building Step; the mediator ontology (developed in the Java Eclipse environment), which uses the Protégé OWL API for storing and reasoning the mapping relations between the reference and the proprietary fact models concepts using an ontology conceptualization format (OWL). For the demonstration of the developed approach, a practical example about an enterprise environment is presented. This example represents and structures business knowledge about some simple business concepts used to characterize the registration process of the enterprise employees and their respective personal information as the “cars” used by them, in their companies.
Fig. 6. Fact Model 2 provided by the enterprise B The first Fact Model (from enterprise A) contains 4 entity types, terms that are connected to a value identifier, the reference scheme and 8 value types, constant value terms. To keep this experimentation simple, the authors decided to only include simple constraints, such as, mandatory constraints, the constraints that are used to define the absolute essential fact types necessary for the business domain to function properly, and uniqueness constraints, used to define the kind of multiplicity shared by each of the fact types. Once through the developed prototype, the analyse of the Fact Model ORM files starts, to initiate the glossary building, the system, with the NORMA API libraries support, extracts all the terms and fact types that form the models. Then the system merges all the terms in a single list of terms and all the fact types in a single fact type list. Subsequently, the system fills dynamically the combo boxes with all the terms and fact types as required. After this, users can review the data that was extracted. As an example, by selecting one of the terms as “Car” (see Fig.7), all the information related to this term, which includes, term’s type, reference scheme, fact types associated to and possible note descriptions are revealed. In this case the system detects the synonym “Automobile” and displays three possible descriptions, a note description of the term “Car” (Fact Model 1), a description based on fact types of the term “Car” (Fact Model 1) and a description based on fact types of the term “Automobile” (Fact Model 2). Then, the poll decides which will be the term that will be part of the reference lexicon, or even define another. After click the “Define Reference” button,
Fig. 5. Fact Model 1 provided by the enterprise A After connected to the prototype user interface each enterprise representative or contributor must upload his/her enterprise business domain structure, which in this 326
INCOM 2015 11-13, 2015. Ottawa, Canada Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307
May 306
Fig. 7. Reference Enterprise Lexicon Establishment
Fig. 8. Reference Fact Model defined and a faceted classification of “has” type
illustrated in the right picture of Fig. 8. This shows a “has” facet classification kind.
the chosen term and description are defined as reference and are added to the glossary. The identified mismatches of the terms are recorded in mediator.
5. CONCLUSIONS AND FUTURE WORK The present prototype only accomplishes the first phase of the MENTOR methodology (Lexicon Settlement). However, to test MENTOR implementation feasibility in relation to fact models, even manually, this case study performed all the MENTOR steps. As a result it was defined the reference Fact Model shown in left part of Fig.8. In addition to the Lexicon defined it was also tested the faceted classification feature as
In this paper an approach to define a reference lexicon from fact models based in the MENTOR methodology is proposed. The approach performs an adaptation of MENTOR, including the integration of a faceted classification functionality, which by accomplishing some automatized features facilitate the generation of a reference thesaurus. This will enable 327
INCOM 2015 Pedro Andrade et al. / IFAC-PapersOnLine 48-3 (2015) 300–307 May 11-13, 2015. Ottawa, Canada
enterprises that use fact models to establish semantic agreements and a reference fact model within their business network to facilitate interoperable communication between their stakeholders’ systems.
307
Halpin, T. (2001). “Object-Role Modeling : an overview,” Retrieved from the web at October 2014: http://www.orm.net/pdf/ORMwhitePaper.pdf. Halpin, T. (2014). “Object Role Modeling - The Official Site for Conceptual Data Modeling”. Retrieved from the web at October 2014: http://www.orm.net/. Halpin, T. and Bloesch, A. (1998). A comparison of UML and ORM for data modelling. In Proceedings of the 3th CAISE/IFIP-WG8.1 International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design. Holsapple, C. W.; Joshi, K. D.; (2002). “A Collaborative Approach to Ontology Design”. In: Communications of the ACM, ISSN: 0001-0782, Vol. 45, pp. 42-47, 2002. Lenci, A. (2002). “Building an Ontology for the Lexicon: Semantic Types and Word Meaning,” [Jensen and Skadhauge (eds.) 01], pp. 103 -120, [http://www.ontoquery.dk/publications/docs/Building_an _Ontology.doc ], 27 November 2002. Lin, H. N.; Tseng, S. S.; Weng, J. F.; Lin, H. Y.; Su, J. M.; (2007). “An Iterative, Collaborative Ontology Construction Scheme”. In: Second International Conference on Innovative Computing, Information and Control (ICICIC 2007), ISBN: 0-7695-2882-1, pp. 150, 2007. ModernAnalist.com (2012). Interview Questions for Business Analysts and Systems Analysts – What is a Fact Model?. Retrieved from the web at March 2015: http://www.modernanalyst.com/Careers/InterviewQuesti ons/tabid/128/ID/1537/What-is-a-Fact-Model.aspx NeOn Project, 2010. Accessed at August 2014: http://www.neon-toolkit.org/wiki/Main_Page Purchase, J., (2010). What is a Fact Model? Why Should You Have One?. Retrieved from the web at October 2014: http://blog.luxmagi.com/2010/04/what-is-a-fact-modelwhy-should-you-have-one/, 2010. Ross, G. R. (2000). What Are Fact Models and Why Do You Need Them (Part 1). Retrieved from the web at March 2015: http://www.brcommunity.com/b008a.php Sarraipa, J., Jardim-Goncalves, R., Gaspar, T., and A. Steiger-Garcao, A. (2010). “Collaborative ontology building using qualitative information collection methods”. In Proceedings of 5th IEEE Int. Conf. Intell. Syst., pp. 61–66, Jul. 2010. Sarraipa, J., Jardim-Goncalves, R., and Steiger-Garcao, A. (2010). “MENTOR: an enabler for interoperable intelligent systems,” Int. J. Gen. Syst., vol. 39, no. 5, pp. 557–573, Jul. 2010. Sarraipa, J., Silva, J. P. M. A., Jardim-Goncalves, R., and Monteiro, A. A. C. (2008). “MENTOR – A Methodology for Enterprise Reference Ontology Development”. In: Intelligent Systems, 2008. In Proceedings of IS '08. 4th International IEEE Conference, Vol. I, 6-8 Sept. 2008. Tudorache, T (2015). Retrieved from the web at 01/2015: http://protegewiki.stanford.edu/wiki/Collaborative_Prote ge Vernadat, F.B. (1997). Enterprise Modelling Languages ICEIMT'97 Enterprise Integration - International Consensus. EI-IC ESPRIT Project 21.859.
For future work, it will be studied more extensively all the available constraints and characteristics of the fact models, taking advantage of them when generating the reference lexicon, but on the other hand also analysing its representation feasibility in the mediator ontology. It would be equally important to accomplish the prototype with all the MENTOR phases procedures handling fact models, which will enable the capability of handling models of multiple types (both Fact Models and Ontologies), in a same approach, and build a reference lexicon between those multiple types. Finally, it will be more explored the faceted classification functionality to build various conceptual structures of the same knowledge model. This integrated with the nature of Fact Models that facilitate models verbalization in sentences will enable the use of natural language processing to automatize the procedure. This should improve the overall and formal understanding of an enterprise business model, which could potentiate the definition of enhanced and dynamic semantic issues resolutions. 5. AKNOWLEDGEMENTS The research leading to these results have received funding from the European Union H2020-FoF-2014 Framework Programme under the grant agreement of the project: Cloud Collaborative Manufacturing Networks (C2NET) nr 636909, which will continue this line of research. REFERENCES Agostinho, C.; Sarraipa, J.; Goncalves, D.; and JardimGoncalves, R. (2011). “Tuple-Based Semantic and Structural Mapping for a Sustainable Interoperability,” in 2nd Doctoral Conference on Computing, Electrical and Industrial Systems (DOCEIS’11), 2011. Ambler, S. (2015). Enterprise Agile: Business Modeling. Retrieved from the web at March 2015: http://www.enterpriseunifiedprocess.com/essays/enterpri seBusinessModeling.html Auer, S.; Dietzold, S.; Riechert, T. (2006). “OntoWiki – A Tool for Social, Semantic Collaboration”. In Proceedings of the 5th international conference on The Semantic Web (ISWC'06). ISBN: 978-3- 540-49029-6, pp 736 - 749, (2006). Dietzold, S. (2011). OntoWiki. Retrieved from the wb at August 2011: http://ontowiki.net/Projects/OntoWiki Fact Based Modeling WG, (2011). “What is Fact Based Modeling” Retrieved from the web at October 2014: http://www.factbasedmodeling.org/. Gaspar, T. (2011). “Methodology for Collaborative Enterprise Reference Ontology Building,” FCT-DEE MSc Thesis, 2011. Retrieved from the web at October 2014: http://hdl.handle.net/10362/5708. Halpin, T. (1989). ‘A Logical Analysis of Information Systems: static aspects of the data-oriented perspective’, PhD thesis, University of Queensland. 328