When an ontology is being developed, it is essential to firstly identify the domain categories and properties that it should represent [1]. In most OE methods, this is achieved by means of a set of initial tasks usually concerning: (i) purpose and scope identification, which settles why the ontology will be developed and determines its domain of enquiry; and (ii) requirements elicitation, which identifies (functional and non-functional) requirements that the ontology and its implementations should satisfy. Frequently, these tasks determine, among other things, what is relevant to the ontology in the form of the so-called Competency Questions (CQs), as occurs in methods such as NeOn [1], Methontology [2], UPON [3], and SABiO [4].
Given their level of generality, many OE methods often focus on defining what-todo, but lack more prescriptive guidelines for specific tasks (how-to-do). This is particularly true in the case of the aforementioned tasks, which are challenging and complex in at least two aspects [1] [4]: (i) they depend on intense collaboration between ontology engineers, domain experts and potential ontology users, wherein the specialized terminology makes communication difficult; (ii) they encompass selection and reuse of the most suitable non-ontological resources (NORs), from an amount of available knowledge resources used by a particular community, and that must have already achieved some consensus level between experts. The reuse of such NORs may lead to a complex re-engineering process, which is called ontologization in [1].
As observed in [1][2] [4], NORs used for Knowledge Acquisition (KA) during the OE initial phase include classical books, standards, glossaries, lexicons and thesauri, as far as they are available in the context. In addition, many OE methods deal with information or data models/schemas as NORs to be reused.
We have noticed, however, that none of the investigated approaches have explicitly explored the use of "process-related models" such as Business Process Management (BPM) and EA models as NORs. These models are commonly available in process-rich social domains (e.g., e-Government, finance, software engineering, manufacturing), and may be employed as valuable sources of consolidated knowledge about the domain(s) in which an enterprise operates. They are often kept in enterprise repositories and reflect the result of significant modeling and validation efforts.
In this paper, we present an approach that employs such type of models as NORs in the OE trajectory. While these models may play a role in KA in general, we focus on their role in supporting the definition of the purpose, scope and functional requirements for an ontology. This is because these models characterize, among other aspects, the organizational context and the business motivations/goals [5]. Therefore, they facilitate the identification of intended uses/purpose of an ontology to be integrated to the EA, as a means to address goals of the organization stakeholders. Furthermore, such models are typically presented in a graphical notation (e.g., BPMN for business process models, and ArchiMate for EA models), favoring communication between domain experts and ontology engineers about the subject domain to be modeled. We show how this approach is being applied in a real-world e-Government project, where we need to develop a network of ontologies to deal with interoperability problems regarding data from public security Information Systems (ISs).
The remainder of this paper is structured as follows: Section 2 introduces the concepts to understand our approach, namely OE initial tasks (purpose and scope identification and requirements elicitation) and EA models and their main elements. Section 3 presents the approach, which is illustrated in Section 4. Section 5 discusses related work, and Section 6 presents some final considerations.
In several OE methods (e.g., SABiO, NeOn and Methontology), most of the KA occurs during the OE initial phase, i.e., in the phases comprising what we term here Early Ontology Engineering. As shown in Figure 1 (adapted from SABiO method), in order to perform this activity, ontology engineers need the collaboration of ontology users and domain experts, and they should also select and reuse suitable knowledge resources, including the so-called non-ontological resources (NORs) [1]. In this paper, we consider EA models developed in the diagrammatic language ArchiMate [6] as NORs. ArchiMate comprises an EA modeling framework and an homonymous EA modeling language [5], whose main objective is to promote the integration of the various viewpoints of the organization, promoting communication between stakeholders and analysis of various aspects of the organization.
The main graphical elements provided by ArchiMate are disposed in three architectural layers: (i) the business layer -which concerns the products and services produced by business processes executed by actors or roles; (ii) the application layerwhich concerns the application software that supports the business layer; and (iii) the technology layer -which concerns infrastructural elements. In this paper, we focus on the elements of the business layer.
We employ two viewpoints in this layer: a motivation viewpoint and a business process viewpoint. The motivation viewpoint explores elements concerning motivational aspects that capture and justify why the business wants to do something, what it aims to achieve, how it plans to get there. The business process viewpoint captures actors and roles and their assignments to tasks/activities within one or across several business processes. The description of the EA modeling elements used in this paper and their notation in ArchiMate are described in Table 1 (the elements of EA motivation models) and Table 2 (the elements of EA business layer). (The descriptions listed in these tables are originated from the ArchiMate specification [6]).
Stakeholder -is the role of an individual, team, or organization (or classes thereof) that represents their interests in the outcome of the architecture.
Driver -represents an external or internal condition that motivates an organization to define its goals and implement the necessary changes to achieve them.
Assessment -represents the result of an analysis of the state of affairs of the enterprise with respect to some driver.
Goal -represents a high-level statement of intent, direction, or desired end state for an organization and its stakeholders.
Business actor -is a business entity that is capable of performing behavior. A business actor may be assigned to one or more business roles. It can then perform the behavior to which these business roles are assigned.
Business role -is the responsibility for performing specific behavior, to which an actor can be assigned, or the part an actor plays in a particular action or event.
Business process -represents a sequence of business behaviors that achieves a specific outcome such as a defined set of products or business services.
Business object -represents a concept used within a particular business domain. Business objects may be accessed (e.g., in the case of information objects, they may be created, read, written) by a business process.
Representation -represents a perceptible form of the information carried by a business object. A single business object can have a number of different representations. A single representation can realize one or more business objects.
In this section, we discuss how EA models can be used for guiding the ontology engineers in the identification of: (i) domain experts and potential users of the ontology, (ii) knowledge resources, (iii) ontology purpose aligned with organizational goals, (iv) ontology scope and requirements. Therefore, the approach consists of the activities that should be performed by ontology engineers helping the specification of the expected ontology from the analysis of EA models. Concerning (i), to guide the identification of the domain experts and potential users of the ontology, the ontology engineer should analyze the motivation element stakeholder, and the business elements actor and role in the EA models. This is because the actors and roles represent the entities responsible for performing organizational processes, and stakeholders represent entities interested in the organizational context, both of which can be considered potential domain experts and/or ontology users.
Concerning (ii), the ontology engineer may identify additional knowledge resources from the analysis of the business elements representation and business object. This is because representations (e.g., documents, messages, models, database or spreadsheet tables) capture the perceptible carriers of information related to business objects, and may correspond to types of NORs proposed for reuse in the literature.
Once the knowledge resources have been identified, the ontology engineer initiates the identification of the ontology purpose (iii), which consists of exploring the motivation elements driver, assessment and goal. In general, the stakeholders are motivated by external or internal conditions, called drivers. It is common for organizations to undertake an assessment of these drivers, which may reveal weaknesses and threats that affect such drivers. Thus, the stakeholders are often motivated to define organizational goals and implement the necessary changes to achieve them. In this step, the ontology to be developed is considered a prospective artifact to take part in the EA, and as such, should have an intended purpose fit to contribute to the achievement of organizational goals.
Furthermore, concerning (iv), and following the recommendations of the cited OE methods to elicit the ontology requirements, the ontology engineer should write them in form of CQs. Considering some business elements in the EA models, the ontology engineer can directly identify "process-related" CQs, as explained below:
-Given that business roles and business actors may represent active entities in charge of executing business processes, a competency question should be elaborated for each specific actor executing a task. These CQs follow the structure: "Which individual playing the <<business role / actor>> is responsible for the occurrences of a particular <<business process>>?" -Given that business roles and business actors also represent active entities impacted by business processes, the following CQs can be structured: "Which individual playing the <<business role / actor>> is impacted by the occurrences of a particular <<business process>>?" -Given that business objects represent information assets accessed by business processes, the CQs that deal with such relation may follow the structure: "Which <<business object>> is accessed by a particular <<business process>>?" -Unlike previous questions, which can be directly inferred from relations among business elements, there may be relevant questions concerning sequences of interrelated business processes. These may require a more complex analysis about: (i) the relations between business roles and/or business actors and different business processes; or (ii) the business objects accessed by a sequence of interlinked business processes. An example of the structure of such kind of CQ is: "Which <<business role>> is affected by a particular <<business process>> as consequence of a previous <<business process>> that triggers the first one?"
Finally, it is important to notice that the "process-related" CQs produced by this approach should be taken as complementary to those suggested by existing OE approaches, which consider other kinds of NORs.
The next section explores each of the steps discussed here in the context of a concrete setting of an e-Government interoperability project.
According to the Brazilian Health Ministry, between 1996 and 2010 there were almost 1.9 million violent deaths in Brazil, including 710 thousand homicides; and 174 thousand deaths whose basic cause could not be determined by the State. That is, violent death incidents of undetermined cause represent 9.6% of all violent events. In developed countries, this proportion is a residue with less than 1% of all violent cases [8]. As Cerqueira noted [8], the lack of consistent and qualified information on crimes and violent deaths in Brazil is caused in part by deficiencies concerning the sharing and dissemination of information among public administration (PA) agencies. Although these agencies have a large amount of information in their ISs, the various ISs function in isolated silos, failing to support overall decision making.
These are characteristic problems of e-Government interoperability [7], going beyond the security sector to many other areas of the PA. Integration efforts in this setting are challenging mainly because the involved IS are often: (i) commissioned and maintained by different agencies; (ii) designed to address different tasks; and (iii) positioned to support different business processes in isolation. In order to understand the current process followed by PA agencies to deal with violent crimes, we used the model presented in Figure 3. It represents the current aspects (a so called as-is model) of the PA agencies involved in the public security sector, by means of: their roles in the violent crime processes, the subprocesses performed by each PA agency, the IS infrastructure that supports these processes and the information flow, and the information artifacts.
The core of the EA model is the "Violent Crime Process" (VCP). The VCP is a complex business process composed by other business processes. These VCP subprocesses are performed by different public agents of the PA agencies as explained in the sequel. Initially, in the "Police Incident Handling" sub-process, the "Military Police"2 receives a request and performs the necessary procedures, while the "Public Safety Dispatcher" creates a "Crime Description", recording information about the police incident (e.g., possible location, time, victim) in the "Police Report", which is used as part of the "Police Inquest". Next, in order to determine authorship of the alleged crime, the "Civil Police"3 establishes a "Criminal Investigation" process, which is composed by: (i) a "Police Investigation" to gather "Evidences" (e.g. crime scene, autopsy and death reports) and "Witness Statements" that are attached to the "Police Inquest"; and (ii) a "Preliminary Police Accusation" based on the "Police Inquest", if the details in the "Crime Description" suffice to name "Formal Suspects" for the crime.
Then, the "Public Prosecutor" analyzes the "Police Inquest" and defines whether to initiate the "Criminal Accusation" process, which starts with the "Indictment", a formal complaint that causes the "Formal Suspect" to become "Indicted". After that, in the "Acceptance of Prosecution" sub-process, the "Judge" analyzes the "Indictment Document" and may accept it, thus starting a "Criminal Trial" in the judicial sphere.
During the "Criminal Trial", the "Grand Jury" hears the prosecution (as conducted by the "Public Prosecutor") and the defense ("Defendant" lawyer), in addition to witness(es) and victim(s), and then announces the verdict. In case of a guilty verdict, the "Judge" pronounces the "Conviction" imposing a penalty to the "Convicted". Thereafter, the "Imprisonment" process initiates, the guilty party (i.e. the"Prisoner"), has to comply with the sentence.
The business objects "Crime Description", "Indictment Data", "Verdict Data" and "Imprisonment Data" represent the information accessed (and changed) by business processes and stored in the related physical objects (representations).
In this section, we apply the approach proposed in section 3 in the context of a realworld e-Government interoperability project. As this section is based in the models presented in section 4.1, the terms "motivation model" and "business model", when used, refer to Figure 2 and Figure 3 respectively.
The first step consists in the identification of the domain experts and the potential users of the ontology. In the public security domain, these entities are the "State Government" and the "Public Administration Agency", depicted in the motivation model. In the business model, these are the "Public Safety Dispatcher", "Police Chief Office", "Public Prosecutor", "Judge" and "Imprisonment Judge".
Furthermore, other potential sources of domain knowledge can be inferred from the analysis of the business objects and representations in the business model. Thus, by analyzing these models, the following such potential resources were identified: "Police Report", "Evidences", "Witness Statements", "Police Inquest", "Indictment Document", "Verdict Report" and "Imprisonment Report".
The second step consists in the identification of the ontology purpose. As seen in motivation model, the driver "Quality of Information about Public Security" motivates the stakeholders "State Government" and "Public Administration Agency" to define organizational goals and implement the necessary changes to achieve such goals. However, there are problems (depicted by assessments) that prevent the stakeholders from having quality information about public security. For example, the problem "Low quality in the criminal information impairs the government strategic decision-making", associated with this driver, reveals itself as a threat to the public security domain. Here, the ontology, to be introduced as a new artifact in this architecture, has the purpose of providing a semantic basis to allow the integration of different criminal ISs. This clarifies the intended role of the ontology in the architecture, and can also serve to communicate this to the stakeholders considering their goals and drivers.
Further, the approach guides the elicitation of ontology requirements in the form of competency question (CQs). From the analysis of the business model, the following information may be extracted:
-By analyzing the business roles and business actors, we obtain active entities (e.g., "Public Safety Dispatcher", "Police Chief Officer", "Public Prosecutor") in charge of realizing some business process (e.g., "Police Incident Handling", "Police Investigation", "Indictment"). These elements allow formulating CQs, such as "Which individual playing the role of "Police Chief Officer" is responsible for conducting a particular "Police Investigation"?" or, also, "Which individual playing the role of "Public Prosecutor" is responsible for conducting a particular "Indictment"?" -By analyzing the business roles and business actors, we also obtain active entities (e.g., "Formal Suspect", "Convicted", "Prisoner") affected by some business process (e.g., "Preliminary Police Accusation", "Conviction", "Imprisonment"). These elements allow formulating CQs, such as "Which individual playing the "Formal Suspect" role is impacted by the occurrences of a particular "Preliminary Police Accusation"?" or, also, "Which individual playing the role of "Convicted" is impacted by the occurrences of a particular "Conviction"?" -By analyzing the business objects (e.g., "Crime Description", "Alleged Victim Description", Imprisonment Data") that are accessed by business process (e.g., "Police Investigation", "Indictment", "Imprisonment") we can formulate CQs, such as "Which "Alleged Victim Description" is accessed by a particular "Police Investigation"?" or, also, "Which "Imprisonment Data" are accessed by a particular "Imprisonment"?" In addition, we identify CQs that transcend business processes performed by different public agencies. For instance: "Which police investigations conducted by a police chief officer led to the effective conviction of the formal suspects?" In this case, we need to understand which are the business roles involved in a police investigation and in a conviction, and how they relate to one another. Beyond extracting the business roles involved in business processes, we analyze the relation between business roles and business processes. For example, the information regarding a possible formal suspect is carried by the business object "Alleged Participant Description" (part of the "Crime Description" and created in "Police Investigation"), and the "Conviction" process accesses this information through the "Verdict Data" (which aggregates the "Indictment Data" and consequently the "Crime Description"). Therefore, if the "Conviction" and the "Police Investigation" share the same information about a suspect, this brings about additional evidences that the "Convicted" and the "Formal Suspect" in a specific crime are the same individual, thus providing a more effective semantic support for deciding that this "Police Investigation" led to an effective "Conviction".
In order to exemplify how these identified CQs support the development of domain ontologies, we present a fragment of the VCP domain ontology, represented in the OntoUML language [9], concerning "Criminal Investigation" (which encompasses the subprocesses of "Police Investigation" and "Preliminary Police Accusation"). This fragment was built using the following CQs: The two relations, namely the historical dependence relation between "Preliminary Police Accusation" and "Police Investigation" and the generalization relation between "Formal Suspect" and "Preliminary Police Suspect", capture two important notions: the former captures the idea that a "Police Investigation" is required for a "Preliminary Police Accusation" to exist; the latter that the "Formal Suspect" must be a "Preliminary Police Suspect" in the scope of a "Police Investigation". We have observed that similar patterns are manifested throughout the whole VCP process.
As previously mentioned, many of the OE methods include the use of CQs to identify requirements. A brief description of some methodologies and their support to CQs definitions is presented in [10], pointing out that most of those methods presuppose the existence of this set of questions (not focusing on specifying how to formulate them) and concentrate their efforts in defining the next stages of ontology development. Despite the importance of eliciting ontology requirements within the field of OE, the existing methodologies make little use of elicitation and modeling techniques [10]. In order to fill this gap between the definition of CQs and the ontology modeling per se, we rely here on the use of EA models.
The approach presented in [10] is the closest to the one presented here that we found. The authors in [10] proposed an OE approach with three main objectives: (i) defining the ontology scope; (ii) deciding the ontology"s applicability; and (iii) specifying what questions the ontology must answer. To achieve these objectives they applied Tropos [11] as the goal modeling methodology. The first activity of that approach is to develop early requirements, which permits to understand the organizational setting as it is. The output of this activity is an organizational model, which includes relevant actors, their goals and interdependencies. This model provides a context for the definition of the ontology scope, helping to identify ontology"s applicability. In late requirements activity of Tropos, the system is modeled as an actor that is dependent of other actors in the organization. These dependencies define the functional and nonfunctional requirements of the system. Such requirements detail what kind of support a system (in our case, an ontology-based system) should provide. Similar to our proposal, they concentrated their efforts in defining the first stage of ontology development. Differently from them, our work is not only based on analysis of the goals depicted in motivation models, but also on the process models. We argue that, using EA process models, it is possible to analyze other organizational elements that impact the ontology specification. We did not find studies that explicitly propose the use of EA models as knowledge resource to support ontology development.
Concerning requirements elicitation, a systematic review reported in [12] has shown that are many proposals using EA models, but all of these concern requirements for software development. The review focused in the requirements extraction from business process models represented in the BPMN notation. In this context, one study that we consider relevant is proposed in [13]. They propose acquiring requirements for software intensive systems according to the business objectives and base lining business processes. The approach consists of the following activities: (i) concepts exploration and orientation; (ii) analysis and modeling of current business processes; (iii) modeling of target business processes; and (iv) requirements generation for the target system. Although they do not focus on ontology development, there are similarities with our work. First, they use the models to understand the current business processes with their business flows, inputs, outputs, and responsible bodies. They also proposed guidelines to get knowledge about the domain using the BPM model, closer to our proposal. Considering the process of requirements elicitation, we focused on the semantics of the elements of EA models and their relations. In contrast, they explain that functional requirements of the target system were elicited by analyzing the business processes, but they do not show how these requirements can be explicitly identified. An advantage of our proposal is focusing on how to do the requirements identification by detailing guidelines of using EA model elements in this activity.
This paper presents an approach for Early Ontology Engineering, in particular for KA support process. We do that by (re)using EA models as a suitable process-based NOR in process-rich social domains. These EA models provide not only a mechanism to systematically structure knowledge about the subject domain, but also provide resources to analyze and understand the organizational elements from different viewpoints.
The proposed approach uses the knowledge assets contained in the (pre-existing) EA models (diagrammatic models about institutional processes, structure, information technology architecture and business motivational aspects) as inputs to Early Ontology Engineering activities in way that: (i) helps ontology engineers to comprehend the overall subject domain; (ii) makes their communication with the domain experts easier and clearer; and (iii) provides guidelines to identify the purpose and scope of domain ontologies as well as to elicit their requirements.
This approach proposes to reuse EA models in enterprise contexts where they are readily available. In cases that these models do not yet exist, the development of new EA models for organizations has become a common practice. In such cases, the EA modeling stage can be a beneficial activity for developing structured knowledge assets in (and about) the organization, enhancing its own EA.
In addition to these aspects, we have also perceived other benefits exploring the use of EA models as NORs in other stages of the ontology development process, which are not explained in this paper for the sake of space. For example: (i) by analyzing application layer elements (e.g., application services, application components and data objects) and technology layer elements (e.g., technology nodes, artifacts, services and softwares), it is possible to point to other useful NORs that can be used to support the identification of concepts and relations for the ontology, and to provide data for the instantiation and evaluation of the ontologies produced; and (ii) by analyzing how the underlying application layer elements support the various business processes, ontology engineers can identify IS interoperability gaps, e.g., observing that the relations between business processes do not have correspondent relations between the application layer elements that support such processes. From this finding, the ontology engineers design an ontology that addresses this issue.
In future work, we intend to investigate: (i) how EA models may support identifying non-functional requirements, e.g. desirable computational properties in order to implement an operational ontology; (ii) the role of reference ontology models to improve EA, i.e., how a developed ontology introduced as an new artifact in the organizational architecture can improve such architecture, providing a precise semantics to domain concepts, thus contributing to achieve the organizational goals.
This research is partly funded by FAPES (69382549), CNPq (grants number 311313/2014-0, 461777/2014-2 and 407235/2017-5), CAPES (23038.028816/2016-41), as well as the Free University of Bozen-Bolzano (OCEAN Project).
In Figure 4, the "Police Investigation" is a relator (roughly, an objectified relational context) connecting the "Investigator" (the role played by a "Police Chief Officer" when performing an investigation) to the "Preliminary Police Suspects" (the role played by a "Person" being investigated). The "Police Investigation" is characterized by an investigation content, which refers to a "Crime Description". This description grounds the indication of some participant as "Preliminary Police Suspect", justifying the relation "refers to" holding between an "Alleged Participant Description" and a "Preliminary Police Suspect".
A "Preliminary Police Accusation" is based on a "Police Investigation" (hence the historical dependence relation [9]). The "Preliminary Police Accusation" mediates the "Accuser" and the "Formal Suspect" (specialization of the "Preliminary Police Suspect"). A "Preliminary Police Accusation", similarly to a "Police Investigation", is characterized by some content, which is captured by the notion of "Crime Description".