This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Abstract- Tendering processes involves tedious and complex procedures. In construction, analysing tender documents is complicated and demanding task which requires in depth knowledge of domain experts. Inconsistency information and lack of knowledge during decision-making process could trigger to wrong decision. In addition, vast amount of information is in unstructured forms need to be managed into a systematic manner. The aim of this research is to develop a generic ontology-based architecture for supporting tendering processes and proves the effectiveness of the approach in construction tender evaluation process emphasizing only on checking sufficiency documents. Here, ontology is built to capture and structure domain expert knowledge based on criteria and preferences demand for tender evaluation.
Keywords-Ontology; Tendering; Tender Evaluation;
Tendering processes involves tedious and complex procedures with conflicting interests between authority parties, multiple sets of objectives, criteria and solution possibilities [1, 2]. In construction domain, selecting the most qualified contractor is one of the critical factor to the successful execution of a construction project in terms of acceptable standards and specifications, within specific time frame and budget. Tender evaluation involves tender documents analysis and is among the most vital process in tendering.
A collection of tender documents usually provides historical and current information regarding on personel background, bidding price, financial position, current and past experiences capability and resources availability of a contractor who bids for quotation. This information is important source in analysing the eligibility of a bidder according to multi qualification criteria. Analysing tender documents is complicated and demanding task which requires in depth knowledge of domain experts in construction tender. This includes knowledge relating to finance and current construction business operations. Traditional decision-making approach to determine the most qualified candidate depends on complicated and uncertain judgements in which it based on the conflicting organisational objectives and past experiences of the evaluators [2-4].
As the result, computational decision support systems (DSS) have been designed to support decision-making at any levels of an organization in construction domain [4-9]. Effective decision is vital for the survival of an organisation. As noted by , "â€¦ the quality, speed and realization of the decision-making can be increased when the right information is available to the right persons, at the right time and in the right form". By referring to , he believed that the capability of decision makers to use all the available and significant information can improve their decisions behaviour. However, decision-making process tends to be complex with the existence myriads of unstructured and ill-defined information. In addition, human being decision maker tends to provide unfair and bias decision based on incomplete, insufficient and unorganised internal and external knowledge . According to , organizations often consider wrong decision support solutions for their particular problem as consequence of information lacking and inability to process diverse volume of information. Thus, the need to identify and organize information not only in terms of its content but also providing semantic meaning by defining the properties of that content is critical to understand uncertain information in complex situation.
Several applications of domain ontology in tendering have been constructed for solving interoperability  and automatic negotiation process . However, as far as we know there is no development of domain ontology for storing semantic knowledge in order to automatically solve tender assessment. This study presents a generic ontology-based architecture to assist decision-making process by modeling domain expert knowledge and preferences demand of tendering processes generally and construction tender evaluation specifically. Further, appropriate inference rules are generated to represent operational knowledge of particular criteria.
The organisation of this paper is structured as follows. Section 2 presents in general current practices of tendering processes as well as summary of current available ontology development methodologies. Further, step-by-step of ontology modelling are outlined in Section 3. In addition, proposed generic tendering ontology and domain-specific tender evaluation ontology are also presented in this section. Finally, Section 4 concludes with a summary of this paper.
Here, two essential components of related research are discussed including tendering processes and ontology development methodologies.
Generic Tendering Process
Tendering processes is coined as all the activities related to managing procurement or tender documents including producing, publishing, aggregating, assessing and awarding performed by awarding authorities in order to acquire certain products or services, while responding and bidding are activities of parties who are interested to win contract [16-18]. Here, the bidder parties are unable to acquire any knowledge regarding on their bidding status. Meanwhile, assessing process is based on a set of predefined rules and criteria determined by awarding authorities.
Tendering processes involve various business procedures begin with tender specification analysis and tender forming, tender invitation, tender evaluation and tender awarding . Based on the analysis on current practices of tendering processes in different domains such as construction, logistics and electronic commerce, we summary main activities of tendering in Fig. 1, representing by grey boxes. Owner, mediator and provider are three parties involve in the process. Role definition of these terms is explained in the next section.
Invitation to tender
Tender specification preparation
Assess tenders and select provider candidates
View tender advertisement
Purchase tender documents
Fill tender documents
Submit tender documents
Short listed candidates
General Tendering Processes
Tender specification preparation is tender making process in which it involves two way communications between owner and mediator and may be repeated a number of times until an agreed tender documentation and specification are met. Invitation to tender is the process to offer tender to interested parties depends on type of tender offer. Interested providers can apply for tender by submitting their bids and qualifications on tender documents. The bids are aggregated and will not be opened until the end of offering date. Subsequently, the process continues with the tender assessment according to some set of predefined criteria and objectives. Normally, the process will be conducted by a group of profesional experts of owner and mediator. Finally, contract is awarded to the successful bidder/provider.
According to , tendering is categorized into paper-based procurement mechanism, web-based electronic commerce as well as auction and negotiation mechanism. Some of the common problems in current tendering mechanisms are associated with automation in terms of difficulties in appropriate matchmaking the needs/offers between parties, automation negotiation strategies and complicated tender assessment. Building a good ontology can solve these problems by capturing tender elements and structuring semantic properties between these elements.
Ontology Development Methodologies
According to , ontology is defined as a body of consensual knowledge that can be reused and shared across applications and groups of people. Constructing domain ontology is time consuming where it requires input and feedbacks from domain expert. In addition, various steps need to be implemented in order to produce a reliable ontology. However, well structured strategies in ontological engineering could reduce time spent in ontology development. Here, we provide justification on the methodology chosen. Table 1 shows the comparison between ontology engineering methodologies based on mature software development process. The main activities in software life cycle was acknowledged, standardized and revised in IEEE Std 1074-1997 .
Comparisons of Ontology Engineering Methodologies Inspired by Software Development Process
Gruninger and Fox
Uschold and King
Methodology proposed by Gruninger and Fox  is more emphasizing on ontology evaluation instead of comprehensive descriptions on each levels of ontological building. Further, they did not include integration, maintenance and documentation phases in their methodology. Uschold and King  outlined better methodology for building ontology as compared to former approach. However, the approach excluded explicit steps on structuring the domain knowledge in conceptual model and maintaining developed ontology.
Methontology  works based on evolving prototype approach as it allows ontology engineer to maintain and update concepts in ontology life cycle. Despite it domain independent characteristic, Lopez et al.  evaluated Methontology as high degree of adoptability for domain experts who are not ontology engineers. Besides, it allows in detail by specifying ontology at knowledge level. Methontology and On-To-Knowledge  are the most compatible methodologies for ontology building as both approaches explicitly compliance with phases as proposed in software development process. However, the ontology development life cycle of On-To-Knowledge is not an iterative approach if comparing to Methontology. On-To-Knowledge only allows the backtracking process start from refinement phase. This model forces ontology engineer to have complete requirement specification documentation before moving to the next phase. Design, evaluation, documentation and maintenance are phases that carried out during the whole life cycle of ontology development. Thereby, each of these phases can be implemented in parallel and reversibly as the terms in particular domain evolves. Thus, Methontology meets these characteristics to build tendering domain ontology.
Ontology modelling consists of series of steps for modelling tendering processes ontology. The phases of ontology modelling as shown in Fig. 2 also can be customized and implemented for other domain applications. Two levels ontologies have been constructed namely as Tendering Ontology and Tender Evaluation Ontology where is discussed details in this section.
Ontology Modeling Phases
Tender Evaluation Ontology
Ontology Modelling Phases and Ontologies Constructed
Ontology Modelling Phases
Ontology development involves several strategies on defining classes, relations, attributes, values and other objects. Methodology for building ontology is Methontology. Thereby, the steps to construct the ontology are based on activities defined in the approach.
Requirement Specification: Requirement is done by collecting information on literatures including journals, proceeding papers, theses, tender documents and other research materials on tendering processes. All of these documents have been analyzed to identify the important knowledge on tendering domain. Furthermore, several series of interviews have been done with domain experts, Consultant from Department of Work (JKR) who are experiencing in construction tendering process in order to identify the domain experts' view on the knowledge to be encoded in the ontology. This phase will answer some competency questions.
Conceptualization: Conceptualization is the process of structuring knowledge into several components such concepts, attributes, relations, constants, formal axioms, rules and instances.
Integrating: Several possible existing ontologies that can be reused with tender ontology are comprehensively searched in Internet. However, there is no other tender ontology has been found especially for construction tender. Meanwhile, the integration process is difficult since it is very hard to find available online ontology. Most of ontology developed in construction field for example in e-Cognos project has not been endorsed publicly.
Encoding: Encoding is the process of modeling knowledge in the real world. All the concepts, attributes, relations, rules and instances identified during conceptualization stage are encoded into knowledge representation language, namely as Web Ontology Language (OWL). OWL language is based on World Wide Web Consortium (W3C) standard. It is serialized using Resource Description Framework (RDF) syntax and the schema language for RDF, called Resource Description Framework Schema (RDFS). The encoding process is supported by using TopBraid Composer, one type of ontology editor software.
Evaluation: The encoded ontology will be evaluated by two types of experts; ontologist experts and domain experts. Ontologist experts are selected based on their experience in developing ontology. Meanwhile, domain experts are chosen among construction engineering people who are experiencing in tendering processes. Any comments and suggestions from ontologist and domain experts will be used to improve tender ontology.
Documentation: Each step and formulation processes used to identify important terms in tender domain is documented. Documentation is vital in order to reduce difficulty in reusing the ontology and increase understanding of the available ontologies for future references.
Maintanence: Any on-going changes on the terminalogy of domain is continuously updated.
Generic Domain of Tendering Ontology
Generic domain ontology is built to store generic knowledge about tendering processes. Table 2 shows the definition of each concepts defined at this level. Meanwhile, Fig. 3 shows the simplified semantic relationships between concepts that contribute to every tendering process. Generic domain ontology is reusable in the given domain specific (tendering processes).
Definition of Concepts in Tendering Ontology
Any party who intend to purchase supplies by requesting for quotation under certain rules and restrictions for the accomplishment of work within some acceptable standards
Any party who intend to sell supplies by responding to tender invitation and submitting tender bidding
Any party who facilitate communication between owner and provider by producing tender based on owner specification, collecting, organizing, aggregating and dispatching information about tender in progress, potential partners, contract awarded and so on. For example, profesional body such as consultant, info broker or software agent
Same definition as owner
Same definition as provider
Same definition as provider
A formal offer to purchase supply subject to agreed rules and restrictions such as budget, time frame, standard regulations and others
Type of tender in which allow the contracting authority (owner or mediator) to consult the provider of their choice and negotiate the terms of the tender offer with the provider
Type of tender in which allow only provider selected by contracting authority (owner or mediator) to submit tender bidding
Type of tender in which allow all interested provider to submit tender bidding in response to a published tender advertisement notice
Any tangible and intangible product that can be offered for sale in order to benefit another
Any intangible product that can be offered for sale to benefit another
Any tangible product that can be offered for sale to benefit another
Standard by which predetermined by contracting authority (owner or mediator) as a reference point to evaluate tender
A piece of written, printed, or electronic matter that provides information or evidence or that serves as an official record
A binding agreement between two or more parties that is enforceable by law
request for quotation
bid for quotation
Domain Specific of Tender Evaluation Ontology
Domain specific ontology is hard to be reused because the nature of this ontology is to describe concepts, relationships between concepts and axioms for particular specific applications. The development of domain specific ontology is generally motivated by particular problems that attempt to be solved. The main purpose of tender evaluation ontology is to give support for tender evaluator to make an efficient decision in selecting the best contractor. Fig. 4 depicts simplified semantic properties of construction tender evaluation domain based on case studies of construction tendering in Malaysia. Grey boxes represent generic concepts inherited from generic domain ontology of tendering processes.
At this stage, we have modeled rules for checking sufficiency of compulsory and supporting tender documents. OWL Pellet inference engine is used to reasoning rules derived in Sufficiency Compulsory Document and Sufficiency Supporting Document concepts. In this way, simpler concept definitions infer complex concept definitions using OWL operators.
Construction Tender Evaluation Ontology
Sufficiency Compulsory Documents
Sufficiency of compulsory documents are evaluated by inferring complex concept definitions from simpler concept definitions. Here, OWL Pellet inference engine is used to reasoning rules derived in concepts. Below is the rule that can be inferred by OWL Pellet reasoned to identify which tenderers that have submitted all compulsory documents.
Sufficiency Supporting Documents
Similar process will be done to identify which tenderers that have submitted all supporting documents required and the example of rule that can be inferred is shown as below:
The research deals with problem to automate tender evaluation process and further to support tender evaluator to make fast and efficient decision. Based on background studies, tender evaluator faces problem in identifying and structuring relevant knowledge during decision-making. Ontology capture and structure semantic knowledge on criteria preferences for evaluating tender documents. Considering to early implementation, application of ontology proves to be beneficial in providing information support for decision-making process emphasizing on checking sufficiency documents. This is on-going research and for future, the approach is expected to cover all the criteria. In addition, we plan to model more rules including mathematical rules using SPIN-SPARQL inference notation support other criteria on evaluation hierarchy.