The top of the hierarchy can start from 0. The properties ac:isMoreGeneral and ac:isMoreSpecific inverse relations are also used to create a specification hierarchy of action categories. To illustrate how it can be used, we translated an example of actions categories ontology from the MIT Process Handbook [ 37 ] of the Distribute via Electronic Store domain [ 39 ].
The resulting ontology is shown in Fig. The listing shows that the Action Category is at level 1 of the hierarchy of categories, this category is composed of three other ones; two are required: deso:buyBooksToStoreAndToOrder and deso:sellViaElectronicStore, and one is optional: deso:manageSolelyInternetDistribution. Listing 1. Action categories ontology snippet from the distribute via Electronic Store Domain. Example of action categories from the Distribute via Electronic Store Domain [ 39 ]. Listing 2 shows the concept cmm:Capability as an rdfs:Class and cmm:PropertyValue as an equivalent class to owl:Thing because it needs to be the most general class to allow for the reuse of existing vocabularies for possible attribute values for example using vcard open vocabulary for defining addresses.
Then, the property cmm:achieves allows linking a cmm:Capability to its corresponding ac:ActionCategory. Furthermore, the property cmm:property allows to create domain-specific properties that will be created as an rdfs:subProperty of cmm:property and will be interpreted as properties of a capability. Finally, the property cmm:hasMostGeneralValue is used to define during the property declaration its most general value. Note that Listing 2 is not a complete listing of the Capability Meta-Model, further details can be found in the online version.
Capability meta-model snippet. One can define a domain-specific capability ontology by modelling its action category and properties. We discuss in this section the various property types that our model supports. We will use the Distribute via Electronic Store domain its set of action categories has already been discussed in the previous section for defining the property declarations that are related to the action categories shown in Fig. Listing 3 shows the N3 [ 40 ] description of the capability desco:deliverViaCourrier see Line 5.
Line 6 links this capability to its action verb from the Action Categories of the domain which is deso:deliverViaCourrier. The rest of the listing illustrates how two properties desco:from and desco:to are defined. Both properties are rdfs:subProperty of cmm:property Lines 10 and The range of the properties desco:from and desco:to is vcard:VCard to refer to an address. More complex and detailed property types are required for modelling more advanced properties. As depicted in Fig. Using these classes separately or in combination, a capability can specify i the possible values properties can have, and ii how to compute their values.
Before detailing these classes, we need to introduce the concepts of Constraint and Expression which some attribute values may refer to. Listing 4. Example of a constraint. A constraint enables to specify the possible values an attribute can have. The class Constraint represents all constraints. The class Expression enables to specify expressions among them the value of a given constraint. The type of the expression, ExprType , indicates how to build the corresponding queries during a matching process.
Listing 4 shows an example for expressing a constraint on the weight of the package. The constraint PackgConstraint is defined in Line 1. The value of the constraint expression Line 5 indicates that the weight of the package has to be lower than or equal to 50 kg. The class ConstrainedValue enables defining the possible values a property can have by specifying a set of constraints on its value. Listing 5 shows how desco:deliverViaCourrier can specify that it can deliver packages of weight under 50 kg. X is constrained by the constraint PckgConstraint Line 6 which was detailed in Listing 4.
Listing 5. Example of a constrained value. A DynamicValue defines how to compute the value of a property which value depends on i consumer provided properties, ii dynamic values or iii hidden variables. As shown in Fig. Listing 6 shows an example of how to compute the shipping price. The value Y , of the property price , is a DynamicValue. Line 10 specifies the formula for computing the price based on the weight of the package. Listing 6. Example of a dynamic value. A ConditionalValue assigns a value to the corresponding property if a certain condition holds.
That is, the value assignment itself is conditional. Listing 7 gives an example showing how to specify a shipping price when the target country is a European country. The value Y , of the property price , is a ConditionalValue Line 3. PriceCondition is a Constraint which requires that the target country is in Europe Lines 9— As it has been previously mentioned, the model proposed in this paper is an update of previous efforts [ 30 , 41 ]. The main updates in the concepts introduced in this paper are shown in Table 3.
Listing 7. Example of a conditional value. In this section, we discuss how the proposed model satisfies the units of analysis identified in Section 2.
Business Systems Analysis with Ontologies - PDF Free Download
The action categories are defined in an ontology of actions with composition and specification relations between them. This model can be further enriched by exploring other relations such as synonymy. Expressiveness—Explicitly capturing functional and non-functional features related to the action performed : contrary to the IOPE paradigm, our model expresses a business capability with a set of properties that can be both functional and non-functional. The related properties of a particular high-level business capability are captured also in a domain-specific ontology.
Expressiveness—Ability to express these features using simple as well as complex types : a property value of a business capability can be assigned any simple value such as string, integer or an address vcard see Listing lst:SDOnto. Furthermore, the proposed business capability meta-model proposes a set of advanced types such as conditionalValue and enumerationValue see Fig. Inferences—Ability to explicitly identify relationships between business capabilities based on their descriptions : the proposed model identifies two relations to capture specification see Definition 3 and extension see Definition 4 relations between business capabilities.
Inferences—Ability to index and search capabilities : Example 2 Hierarchy of Capabilities shows how an indexing structure of business capability can be constructed based on their proprieties. However, this paper did not elaborate of how specification and extension relations can be extracted and used for building such structure. Future works will use this feature to build an indexing structure of business capabilities based on their properties.
Use of Ontologies—Use of domain or general ontological concepts for describing business capabilities : actual business capabilities are derived from high-level ones that are defined in domain-specific ontologies. In the examples shown in this paper, we illustrated the use of general and domain-specific ontological concepts. Use of Ontologies—Searching capabilities should not be relying on keyword extraction and comparison : capability are described using ontological concepts, this allows the development of mechanisms of discovery using those concepts without relying on extraction of keywords from textual descriptions.
Future works will focus on the indexing and discovery of business capability using this modelling approach. In this section, we provide a proof of concept to show how we can use the capability model to annotate tasks of a process model. It is important to note that our vision for describing business capabilities is to abstract from any service or process modelling language.
In other words, a capability of a process task can be described in RDF outside the scope of the process model; while a link between the task and its capability needs to exist. Existing annotation mechanisms such as in Business Process modelling Notation 6 BPMN for short can be used to create this link but not for describing the capability. Using BPMN annotations as capability attributes loses the connection between the capability as an entity to its action categories and related properties. For other languages that do not provide annotation mechanisms such as EPC, additional changes in their specifications might be required.
As it is difficult for new users to write RDF annotations for describing the capability of their services or business processes, we have implemented an extension of EPCTools 7 [ 45 ], a business process modelling tool using EPC, in order to assist users in the annotation operation. Figure 8 shows screenshots of the extended version of EPCTools. When a user wants to annotate a particular task of a model, he needs to right click it and choose Capability from the contextual menu see 1 in Fig.
After loading the required ontologies, the user has to select the action category for the current task see 2 in Fig. Finally, the user has to choose what properties associated to the action category he wants to define in his capability see 3 in Fig. Note that the primary purpose of this tool support is to provide a proof of concept for testing the applicability of the proposed model. A proper evaluation of the model itself is carried out in Section 6.
While process models explicitly capture the involved activities and workflows together with organization-specific resources, the proposed capability model focuses at providing an abstract representation of what these processes achieve or the outcome that customers or collaborators need.
Within the same organisation, there may be several workflows for specific outcomes e. The model proposed can serve this need, however, at least one further steps is required: identification of the business capability of an entire process given that all of its activities are annotated with their business capabilities. Values of these concepts depend on the control flow of the process model as well as the capabilities of all its activities i.
The action category is a mandatory property in the business capability description. Its value is taken from an Actions Ontology that is also used for determining the action category of aggregated business capabilities. An aggregated business capability has as action category corresponding to the Lowest Common Ancestor LCA of the action verbs of its components. Using the ontology of Action Categories depicted in Fig. Ideally, all the action categories used in the model are taken from the same actions ontology like in this simple example.
For various reasons, modellers can use actions taken from different action ontologies. Instead of searching for the LCA in a single actions ontology, one needs to take into account all the possible ontologies used in assigning action categories to the capabilities of a process model. In such a case, a more elaborated method is needed [ 38 ]. Properties of a capability of a business process model can be determined by propagating them from a start node to an end node.
Each node introduces new properties with respect to various conditions e. In order to propose a correct properties propagation algorithm, we assume that the input process model does not have any loops and is well structure. In a well-structured process model, every split connector has a corresponding join connector, whereas both connectors bound a process model fragment with one entry node and one exit node [ 46 ].
We propose to use the formal semantics of the business capability annotated business process graph as a token game, similar to Petri Nets [ 47 ]. Petri nets can be used to represent dynamics of business process models by using token propagation to verify if models are regular, sound and well structured [ 48 ]. A token is a theoretical concept that is used as an aid to define the behaviour of a process by firing its nodes.
The Initial place generates a token that traverses the sequence transitions and passes through all the places until reaching the Final place [ 49 ]. In this case, a process model is mapped to a petri net using transformation rules depending on the type of its nodes. In EPC, function and event nodes are transformed into transitions and places, respectively, while mapping connectors is more complex.
This depends on the type of connector and its linked nodes [ 48 ]. The idea of propagating the properties of a process model is similar; it starts from the InitialNode then fires all the nodes one by one and propagates the subsequent properties until it reaches the FinalNode. Each node introduces some changes on the set of propagated properties. The propagated properties at a particular node are marked on its outgoing arcs. The propagation of properties and conditions is then guided by the traversal of tokens in the petri nets representing the business process model.
However, classical petri nets allow only the modelling of states, events, synchronizations, etc. To solve this issue, coloured or typed petri nets [ 50 ] have been introduced as an extension to classical petri nets where tokens represent objects e. At each transition, a token is produced with respect to the consumed tokens. More concretely, a transition represents a relation between input and output tokens. Our proposed propagation algorithm [ 51 ] defines the relations of these transitions. The idea of this propagation has been used in the literature for propagating IOPEs of process models to determine their IT capabilities [ 52 ] as well as for the verification the soundness of business process models [ 53 ].
The proposed business capabilities aggregation algorithm has also been implemented as an extended version of EPCTools 8 [ 45 ]. This extension shown in Fig. The result is shown to the user as a set of action categories see Area 2 in Fig. Note that the objective of this tool is to provide a proof of concept for determining the capability of an entire business process model.
It has been developed to show the applicability of this approach, to carry out some manual verification of the results and to be used as a visual support for conducting interviews with domain experts. Apart from this running example, we manually tested this algorithm on a set of process models from the customs clearance processes: import procedures. The test collection includes 10 business processes that have been previously subject to a case study [ 54 ] for capability modelling in logistics. They describe guidance on the basic regulatory requirements that all importers must consider for importing goods.
These processes involve various steps from submission of import documents until the release of the imported goods. In Section 6. We propose to validate the business capability model proposed in this paper using ontological evaluation as a non-empirical evaluation method see Section 6. However, mapping the modelling language constructs to ontological concepts can be subjective especially when we want to identify intrinsic and non-intrinsic attributes or classes and kinds, consequently this can lead to a subjective evaluation. To avoid this issue, Wand et al.
In this approach, the evaluation of the model is carried out through the verification of a set of rules insuring that a model does not generate any semantic ambiguity by avoiding construct overload and redundancy. These rules are not related to a particular conceptual model and can be applicable to any model that is using generic ontological concepts. Therefore, we evaluated the proposed business capability conceptual model using this methodology.
The first step of the evaluation consists of mapping the business capability conceptual model constructs to the generic conceptual model constructs proposed by Wand et al. Table 4 shows the mapping that is used for the second step of this evaluation that consists of verifying that the model respects a set of rules defined by Wand et al. Instances should represent only things. Mapping the business capability conceptual model constructs to generic conceptual modelling constructs and ontological constructs.
In the business capability modelling approach proposed in this work as well as in other modelling paradigms e. Object-Oriented modelling , things represent objects representing instances of classes. Rule 1 implies that things cannot be instances of attributes or other instances. This is true for all the attributes shown in Table 4 except for Property Entry.
The model that includes such constructs should define how it can be interpreted. In this work, for creating a domain-specific business capability property, the model suggests to create an instance of a Property Entry that links a Capability instance to a certain Value. For this reason, in the implementation of this business capability meta-model, the Property Entry is defined as an rdf:Property see cmm:property in Listing 2 and all business capability properties are created as rdfs:subProperty of cmm:property see desco:from in Listing 3. The business capability meta-model proposed in this paper does not differentiate between simple and composite business capabilities.
Both can be presented as instances of the class Capability. Instances of all classes in the business capability meta-model are defined by a set of attributes that are derived from intrinsic as well as mutual properties of the proposed model. This rule does not apply in the case of the business capability meta-model proposed here as there are no aggregated classes in the model.
Instances of the classes proposed in the business capability meta-model are created as objects with a set of properties.
Services on Demand
These properties are either intrinsic or derived from mutual relation. Additional instances of business capabilities have additional attributes that are derived from the Property Entry. The business capability meta-model does not allow the creation of instances without attributes. Most importantly, it does not allow the creation of a business capability without at least specifying its Action Category i. This rule is already covered by the mapping proposed by Wand et al. Indeed, both binary and higher-order relationships are mapped to Attributes.
Furthermore, the business capability meta-model proposed in this paper does not have any higher-order relationships. The above-mentioned rules i. Rules 1 — 7 , as articulated by Wand et al. Researchers such as Bunge [ 55 ], Wand et al. The proposed business capability meta-model is, effectively, representing real things, i.
The main observation is that business capabilities are not tangible objects and might need more flexibility to give the designer the possibility to model these actions as he perceives them. Weber [ 56 ] is in favour of such flexibility and argues that ontological foundations for information systems design might be subject to the perception of the designer. This is also aligned with paradigmatic approaches where conceptual models can capture different aspects of things depending on the intended perception and use of the conceptual models.
The idea of validating conceptual models using ontological analysis can be challenging and difficult to apply with complex models, especially when using the ontological analysis of Bunge [ 55 ]. This can be simplified by using the method proposed by Wand et al. The evaluation of the proposed business capability meta-model using this method was relatively simple as the model defines 14 constructs. This made the verification of the rules of Wand et al.
In this part of the evaluation, we carry out two rounds of semi-structured interviews [ 13 , 14 ] with 10 domain experts that have strong background and are currently active in the area of service computing and information system design and development. The objective of the two rounds a slightly different. The first one aims to assess the intuitive appeal of the capability modelling approach while the second examines the capability aggregation work.
The reasons for these two interviews come from the fact that both contributions were not evaluated at the same time. First we conducted the assessment of the model, once validated we proceeded with the capability aggregation work and carried out the second round of interviews. For each round of interviews, five different experts were invited. For these semi-structured interviews, 10 participants were recruited from different levels of expertise in the area of service computing and information systems design and development.
This number is estimated to be sufficient given that experts are not always available to take part of such experiments [ 57 ] used seven experts in an experimental application of the Delphi method. The age group of these participants is 30—50 years old and their professional background includes a minimum of 5 years experience and are currently active in their field.
The profiles of the experts interviewed in the first round include: two project managers P1 and P2 : leading teams of developers of information systems for the management of seaports in different countries;. One of them is also a manager of his own start-up offering automated post services;. The profiles of the experts interviewed in the second round include two system architects P6 and P7 : working as designers of information systems for clients of a multinational company;.
The approach used for both rounds of interviews follows the case study research process proposed in [ 58 ]:. First round of interviews : Case study design : the objective of the first round of interviews is to assess the intuitive appeal of the proposed model and the objective for the second is to assess the usefulness and intuitive appeal of the proposed aggregation algorithm for identifying the business capabilities of a process model.
Interviews run individually using online conferencing and desktop sharing tools to allow the experts to use the tool themselves remotely. Each position relates to other positions through subordination relationships. An Agent represents a profile that allows the organization to accomplish its mission throughout the execution of activities and it can represent a function or position.
Staff allocation involves selecting people for positions, taking into consideration people's functions and competencies and the functions and competencies required by the positions. People also take part in committees inside the organization. A Committee is a group of people with a specific goal that usually work together for a period of time until a specific goal is achieved, for example: a committee for planning a new product or a committee for guaranteeing security at work.
Finally, Objectives are statements about the results to be reached in a fixed period of time and may be applied to the organization, organizational units or positions. Table 3 and 4 respectively show the main relations and axioms of this sub-ontology. The Artefacts sub-ontology groups the concepts and relationships that define artefacts in terms of their nature and composition.
Business Systems Analysis with Ontologies
An Artefact is anything produced by humans and not by natural causes that is able to exert different roles in an organization, such as the product of an activity. Artefacts can be composed by other artefacts and are classified according to their nature into goods, documents and components. Goods can be classified in goods for use and goods for production. Goods for production can in turn be classified into hardware, software and device.
A Component can be a hardware component , a software component or a spare part. Table 5 and 6 respectively show the main relations and axioms of this subontology. To understand Table 6 , the more complex concept predicate must be explained: component s,t , which means s is a component of type t whose possible values are SoftwareComp, HardwareComp or SparePart. The aspects covered by the Behaviour sub-ontology 3 include: activity as an action of transformation, taxonomy of activity, process and activity breakdown, adoption of procedures, taxonomy of procedures, method as systematic procedure, automation of procedures, organizational processes and related norms as well as organizational projects.
An activity can be classified in operational activity, managerial activity or quality control activity according to its nature and into a main activity or a support activity according to its role in the fulfilment of the organization's mission. An activity can also be made up of a set of other activities. A Process is a set of structured activities which produce artefacts or services of value to the organization itself, for a client or for a business market.
Procedures are instructions for executing activities and are classified into methods, techniques and guidelines. Methods as well as Techniques can be classified according to the type of activities they can support. Guidelines are further classified into templates and norms. A procedure may be supported by 3 Behaviour sub-ontology was defined based on the software process ontology defined by Falbo . An organization has its behaviour defined by the set of processes executed within it and they may comply with norms. Projects are undertakings initiated by the organization which entail processes to guide their activities and have project teams allocated to them.
Table 7 and 8 respectively show the main relations and axioms of this subontology. An organization works in a knowledge domain which means it possesses intellectual capital related to the domain and executes activities which require knowledge from this domain. A Service is an abstract notion, an intangible product offered by an organization to satisfy the need or desire of a client or market, as opposed to an artefact which is a tangible product.
A Business Agreement is an agreement among two or more organizations which establishes a business relationship. Tables 9 and 10 show the main relations and axioms of this sub-ontology. Integration between Knowledge Management and Business Process Modelling has been the trend since . The idea is to make Knowledge Management part of the existing business processes, revising them to accommodate Knowledge Management. The use of business process models as a dimension for organizing corporate knowledge makes the deployment of the required knowledge to the right person at the right time easier.
Furthermore, business process models capture organizational knowledge on how to fulfil the organizations' mission. Capability Management is a sub-area of Knowledge Management whose goal is to understand the competencies that an organization needs to accomplish its business objectives.
It consists of identifying which individual abilities exist within an organization and comparing the required knowledge with the available knowledge to allow the filling of gaps to help achieve the strategic goals of the organization . Moreover, the management of people allocation to software projects can be enriched through the use of the concept of "corporate yellow pages", where information on the competence profile of each professional of the organization is kept .
With this, each professional profile can be captured, mapped in accordance with some previously established criteria, stored and continuously updated. Searches on this database are necessary in order to allocate the most suitable people for the tasks. The analysis of corporate yellow pages is of great importance when there is a need to find experts in an organization. Most of time the desired competence exists somewhere inside the organization, however, it often takes time to identify, locate and gain access to the person who possesses it .
Yellow pages offer a way not only to organize and keep control of the competencies, but also to search for the people that possess them . Sapiens is a 'yellow pages' software tool whose purpose is to allow software developers and project managers to quickly identify within a organizational structure the most appropriate professionals to solve a given problem, as well as to supply knowledge about the organizational structure itself.
To this end, Sapiens contains a representation of the organizational structure with the competencies required in its positions; staff allocation, including the competencies of each professional; and also search and navigation mechanisms. In this way it is possible to create a culture of identification and dissemination of the existing knowledge as well as communication among employees and this can be used by the organization to know itself better and take greater advantage of its potential.
Sapiens is designed to be generic, independent of a specific organization or domain, making use of the Enterprise Ontology to allow the description of any organization and, when appropriate, deals with its clients, technical partners and suppliers. Sapiens can also offer support to the activities of the People Management Department.
For each position in the organizational structure, it is possible to indicate which competencies are necessary obligatory or relevant non-obligatory for its performance. In a similar way it is possible to indicate which competencies a person possesses. The association between people and competence, as well as between position and competence, must take into consideration the level of the competence involved. Each competence is associated to a specific scale. For example, a scale for a specific skill could be made up of the following items: "Does not possess the skill nor took part in training", "Took part in training", "Capable with ability", "Capable with great ability".
For capturing information to fulfil Sapiens' database, we requested people from the organizations to fill in a form to collect their professional profiles and organization representatives to provide information about the organization's structure and the competencies required in each position.
Professional profiles are verified for reliability at the beginning of a new project and updated according to the real performance by project managers using the RHPlan tool see section 4. Sapiens can also be used by authorized people to update professional profiles at anytime. Through these mechanisms the reliability of the organization's 'yellow pages' is continually improved. The organizational structure can be viewed using an organizational chart that shows the subordination relationships among organizational units and allows the visualization of each item details.
A hyperbolic tree structure  as shown in Figure 4 , recommended for visualization of great amounts of organized data in a hierarchical form, is used to browse through the contents of the tool database by exploring the relationships between the items that make up this database. The initial root node is the organization itself. From this point of view the user can browse through its relationships with the other items in the database. When the user clicks on an item, data relative to it are shown see Details box on the right side of Figure 4 and the focused item and its relationships with the other items become more evident.
For example, when the user clicks on an organizational unit such as the "NPqD" in Figure 4 , the existing positions inside this unit appear in the centre and then the user can see who has been allocated to the positions and which competencies are related to each one. In order to do searches on the database, Sapiens provides some search options. However, the user can create a totally new one if desired. Examples of search options include: "Who has a specific competence? The concepts and relationships described by the Enterprise Ontology have guided and restricted the construction of the class model used by all tool modules.
Each class of this class model keeps a reference to the ontological concept that originated it. For implementation reasons, not all the relationships described in the ontology are mapped on the class model. When doing searches, the relationships described in the ontology become important to allow the identification of related concepts and, consequently, of related classes in the class model.
Thus, ontology representation is much used in the search module, considering that ontologies are particularly useful for knowledge recovery and access . When a professional profile is being recorded or updated, the knowledge a certain employee has is also associated to one or more concepts of the EOSDE ontologies and their instances in order to facilitate this information recovery. For example, knowledge about the Use Case Points technique is associated with the concept "Technique" and its instance "Use Case Points".
In turn, Sapiens' previously defined search options have been created on the basis of the existing relationships among Enterprise Ontology concepts. Each pre-defined search contains a description, an item to be looked for based on an ontology concept and a related item based on another ontology concept related to the first. In case the user does not wish to carry out one of the listed search options, the existing concepts in the Enterprise Ontology are shown.
Figure 5 shows Sapiens' search form. Another use of the Enterprise Ontology is in the report exhibition. RHPlan is a software tool to support the planning of human resources for software projects based on organizational knowledge about the corporate competencies and allocation of staff. The resource planning activity is carried out during project planning, when the appropriate competencies to perform the project activities need to be identified so that people can be allocated to the project.
The knowledge used by project managers to do this must be shared across the organization so that the organization can learn from its previous successes and failures. Both manipulate the organization's knowledge map and benefit from the same mapping infrastructure of the ontology concepts for physical model classes. The RHPlan tool also uses the concepts defined in the sub-ontology of Behaviour to describe processes, activities and the necessary competencies for the accomplishment of activities. A screenshot of the RHPlan tool can be seen in Figure 6.
It illustrates the selection of professionals for a software project, but on the vertical bar on the left all the activities supported by the tool for planning human resources are listed: definition of profiles needed for the execution of each process activity, selection of professionals, request for hiring or training for professionals when the available professionals in the organization do not fit the desired profile, and visualization of the human resources plan.
The first step in planning the human resources for a software project is the identification of the necessary competencies to perform each project activity. After this, the right professionals can be selected by comparing the necessities of each activity and the competencies of each professional in the organization Figure 6. On the left the user clicks on a professional profile specified for carrying out an activity and then can see the academic degree and the competences required for it.
The professionals whose characteristics match the profile defined are shown on the right side. The user has access to the academic degree and the competences of a professional by clicking on it. On analysing the profile of the professionals presented by the tool, the project manager should be able to select the most appropriate individuals to take part in the project. During the project a manager can monitor human resources by checking the execution of previous activities and allocating or reallocating selected professionals for the next ones. Periodically, throughout the software project life cycle, and after its conclusion, the human resources can be evaluated.
RHPlan does not support these evaluations, but once poor performances are identified, corrective actions can be adopted, assigning a new resource to the activity or providing training to the currently allocated professional. Green , Michael Rosemann. Ontology, In Craig, E. Volume 7, Nihilism — Quantum mechanics, interpretation of. Information systems development and data modeling: Conceptual and philosophical foundations Peter Aiken.