International Construction Specialty Conference of the Canadian Society for Civil Engineering (ICSC) (5th : 2015)

An ontology-supported transaction formalism protocol in infrastructure management Zeb, Jehan; Froese, Thomas Jun 30, 2015

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
52660-Zeb_J_ICSC15_247_An_Ontology_Supported.pdf [ 375.98kB ]
52660-Zeb_J_ICSC15_247_An_Ontology_Supported_slides.pdf [ 2.01MB ]
Metadata
JSON: 52660-1.0076344.json
JSON-LD: 52660-1.0076344-ld.json
RDF/XML (Pretty): 52660-1.0076344-rdf.xml
RDF/JSON: 52660-1.0076344-rdf.json
Turtle: 52660-1.0076344-turtle.txt
N-Triples: 52660-1.0076344-rdf-ntriples.txt
Original Record: 52660-1.0076344-source.json
Full Text
52660-1.0076344-fulltext.txt
Citation
52660-1.0076344.ris

Full Text

5th International/11th Construction Specialty Conference 5e International/11e Conférence spécialisée sur la construction    Vancouver, British Columbia June 8 to June 10, 2015 / 8 juin au 10 juin 2015   AN ONTOLOGY-SUPPORTED TRANSACTION FORMALISM PROTOCOL IN INFRASTRUCTURE MANAGEMENT Jehan Zeb1 and Thomas Froese1  1 Department of Civil Engineering, University of British Columbia, Vancouver, Canada Abstract: Infrastructure organizations use diversified information systems to exchange data (transaction). Presently, data exchange in the area of infrastructure management is accomplished in a manual and ad hoc basis. The growing trend is to transform these manual data exchanges to a computer-to-computer based exchange of information. “How to formalize these data exchanges or transactions?” is the core research question, which was dealt with developing and applying an ontology-supported Transaction Formalism Protocol (TFP). The proposed solution is composed of two parts: ontology and protocol. Two ontologies, the Transaction Domain Ontology and Tangible Capital Asset ontology, were developed using an eleven-step methodology to represent transaction knowledge and Tangible Capital Asset knowledge respectively to support the design and implementation of transactions in infrastructure management. The proposed TFP is an eight-step procedure developed using a four-step methodology from two perspectives: the TFP Specification modelled each step of the protocol as a function for which inputs, controls, mechanisms, tools/techniques, and outputs were defined, whereas the TFP Tool includes a set of forms and guidance developed for specific steps of the protocol.  The TFP was applied to develop transaction specifications for the Asset Inventory and Condition Assessment Reporting/Tangible Capital Asset (AI&CAR/TCA) Reporting, which was implemented in the Asset Information Integrator System for the exchange of Tangible Capital Asset information between the municipal and provincial governments. The main contributions of this research work include the development of the two ontologies, protocol, and Asset Integrator Information System.   1 INTRODUCTION Infrastructure agencies, including shallow utilities own, operate, and manage infrastructure systems using a wide range of information systems, each based on different proprietary data models. Various agencies and utilities interact with each other and exchange infrastructure information to accomplish a wide range of collaborative tasks. As infrastructure agencies increasingly rely on computer-based systems to manage infrastructure data, much of the information that was traditionally exchanged using manual and ad hoc communications can now be exchanged electronically through computer-to-computer data exchange. This allows for more extensive, rapid, and error-free exchange of information, but it requires more formal specifications to govern these data exchanges (i.e. transactions). A transaction is defined “as any communication or interaction between the sender and receiver roles that make up the information flow through a single or collection of a sequenced set of messages” (Zeb and Froese, 2012). Transaction example includes: communications during a disaster response (“Is power available in this area?” “Who is responsible for this section of roadway?” “When will water to be restored to this area?”); coordination between buried utility agencies; aggregation of data from multiple infrastructure management software with regards to the asset inventory and condition assessment reporting and formalized transactions used in the multi-agency situational awareness system wherein the provincial government requires information 247-1 from many other organizations outside the provincial jurisdiction to prepare for and mitigate the impacts of emergency incidents (Stewart, 2010). Although the inevitable trend in the communication technology is towards increasing computerization, which requires transaction formalization, but there are many challenges that prevent this formalization from being an easy or efficient process. These challenges include: lack of an appropriate process for carrying out this formalization; heterogeneity in data formats, data (class) definitions, and data aggregation (Felio, 2012). These issues were dealt with developing an ontology-supported Transaction Formalism Protocol (TFP) in the domain of infrastructure management.  The TFP is a procedure developed to formalize transactions and create transaction specifications effectively and efficiently. To support the development and application of the TFP, two ontologies were built: the Transaction Domain Ontology (Trans_Dom_Onto), and the Tangible Capital Asset Ontology (TCA_Onto). According to Gruber (1995), an ontology is a “formal explicit specification of a shared conceptualization.” The Trans_Dom_Onto represents transaction related knowledge to support the design, management, implementation of transactions, and development of the TFP. The TCA_Onto represents the Tangible Capital Assets (TCAs) to support the design of message templates in a neutral data format to address message-based interoperability between information systems of the infrastructure organizations. According to PSAB (2009), the TCAs are “non-financial assets having physical substance that are acquired, constructed, or developed and: are held for use in the production or supply of goods and services; have useful lives extending beyond an accounting period; are intended to be used on a continuing basis, and are not intended for sale in the ordinary course of operations.”   The proposed TFP protocol is an eight-step procedure that was developed from two different perspectives. The TFP Specification represents each step of the protocol as a distinct function for which inputs, controls, mechanisms, tools/techniques, and outputs were defined. The TFP Tool is comprised of a set of Excel-based forms and guidance developed for specific steps of the protocol that the transaction development personnel can use to define transaction specifications for IT based solutions.  The proposed TFP was applied to develop transaction specifications for the Asset Inventory (PSAB, 2008) and Condition Assessment (SORP, 2008) Reporting/Tangible Capital Asset (AI&CAR/TCA) Reporting. The formalized transaction specification was implemented in a prototype Asset Information Integrator System (AIIS). The prototype system collects, stores, visualizes, and analyzes the asset inventory and condition assessment information received from different municipalities to help the provincial government to: understand long-term financial needs of municipalities for infrastructure management; develop a consistent and planned approach for funds allocation; and present the case to the federal government for additional funding, if required. This paper is divided into the following seven sections. Background information and related literature are discussed in section 1 and 2 respectively. Section 3 describes the methodology used, whereas section 4 briefly explains the development of the ontologies and TFP. Application of the TFP is presented in section 5 and evaluation is elucidated in section 6. Conclusions and contributions are discussed in section 7.  2 LITERATURE REVIEW  The literature review is discussed from two perspectives: ontologies in the domain of infrastructure management and related work process and communication formalization standards and methodologies. Ontologies in infrastructure management—three ontologies in the domain of infrastructure management are of particular importance: Infrastructure Product Ontology, IPD-Onto (Osman, 2007); Infrastructure and Construction Process Ontology, IC-Pro-Onto (El-Gohary, 2008); and Actor Ontology, Actor-Onto (Zhang and El-Diraby, 2009). The IPD–Onto  (Osman, 2007) represents infrastructure product knowledge (e.g. pipe, valve, pump, etc.). The IC-Pro-Onto represents process knowledge, e.g. core design and construction processes, management processes, knowledge integration processes, and support processes (El-Gohary, 2008). The Actor-Onto represents knowledge related to various actors and actor-roles in the construction industry (Zhang and El-Diraby, 2009). While these three core formalism 247-2 dimensions have been completed, there remains a need to formalize information exchange processes (transactions) to enable computer-to-computer, message-based exchange of information. Transaction formalism involves specifying and defining not only the process, actor and infrastructure system information, but also the specification of information exchange details, which is to be addressed through the development of the Transaction Domain Ontology (Trans_Dom_Onto). In addition, these ontologies do not completely support the design of the message templates that are required to be exchanged in the AI&CAR/TCA Reporting (information transaction). The IPD-Onto doesn’t represent a complete set of the infrastructure products, and it was extended in this research in terms of the TCAs to provide payload information for the design of the message templates for the AI&CAR/TCA Reporting, which led to the development of the TCA_Onto. The header information in these message templates, meanwhile, was captured from the Trans_Dom_Onto that was developed as part of this research work.  State-of-the-art standards—some process and communication formalization techniques currently exist in the Architecture, Engineering, Construction and Facilities Management (AEC/FM) industries, but these standards do not fully address the requirements for transaction formalism in the domain of infrastructure management. In the AEC/FM industries, the Information Delivery Manual (IDM) formalizes work processes in the construction industry (IAI-IDM, 2012). It is a requirement specification methodology focusing on model-based exchange of information between different parties using building information models (BIM). The IDM defines information in terms of informational elements (objects and their attributes) rather than informational products (documents), hence the methodology is BIM specific. In addition, the exhaustive nature of the IDM makes it time-consuming to develop and difficult to share with others on projects (Berard and Karlshoej, 2012). Because of the IDM’s explicit focus on BIM, it does not meet the requirements for a general communication formalism technique for the infrastructure sector, but it is a very relevant exemplar for this research work, and therefore, some features of the IDM specifications were adopted with modifications. The Model View Definition (MVD) is a methodology developed to formally define a subset of an Industry Foundation Class (IFC) BIM model (IAI-MVD, 2005). The MVD is relevant since it is typically used to formally specify the particular BIM information to be exchanged during a specific type of data transaction, but again, it is BIM specific and it lacks a step-by-step procedure describing how to capture requirements. The Voorwaarden Scheppen Voor Invoering Standaardisatie (VISI), which means “Terms and Conditions for the Implementation of Standardization in ICT” is a Dutch communication management standard developed to define transactions in the AEC/FM industry (VISI, 2011). The VISI standard lacks a step-by-step process to capture transaction requirements and define transactions, and it depends on an Extensible Markup Language (XML) based model representing information in a local context (i.e. the Dutch construction industry). A related standard, the Construction Objects and Integration of Processes and Systems Engineering Method (COINS-EM/CEM), is a Dutch standard developed to create agreements on working methods and organization of production processes and information (Schaap et al., 2008). As with the IDM, COINS-EM/CEM focuses on exchange of model-based/3D object data rather than communication in general, and it also lacks a systematic procedure for requirement specification. Another initiative, the agcXML, focused on developing a set of XML schemas to enable industry experts to exchange electronic building information reliably and efficiently between heterogeneous proprietary software applications to improve interoperability and integration of the information systems (Zhu, 2007). The agcXML doesn’t include a general data transaction specification, it does include a format for transaction use cases and a use case for generic document distribution (Froese, 2007), but does not include a procedure for transaction design.  In summary, none of the standards discussed above fully meet all of the objectives of this research work in terms of developing a step-by-step procedure to define transaction specifications in the domain of infrastructure management. Most of the standards are work-process-centric rather than communication-centric. Most do not address how to assess needs and capture information that is required in a given communication. Most of the standards are IT-expert-centric and are not suitable for the end users. These shortcomings led to the development of the proposed ontology-supported TFP.  3 METHODOLOGY Methodology to develop ontologies—a ten-step methodology was devised to build the Trans_Dom_Onto and TCA_Onto, which was a hybrid version of the various approaches developed by Fernandez-Lopez et 247-3 al., (1997); Uschold and Gruininger (1996); and Noy and McGuinness (2001). (i) Define ontology coverage—purpose, use, and users of the ontologies are defined in this step. (ii) Capture competency questions—a set of competency questions were developed that the ontology should be able to answer. (iii) Generate/create taxonomy—a preliminary taxonomy of various concepts was developed. (iv) Reuse existing ontologies—as long as possible, use was made of the existing ontologies and relevant concepts were captured from existing ontologies. (v) Develop Transaction Domain Kernel Ontology, (Trans_Dom_Kernel_Onto) and Tangible Capital Asset Kernel Ontology, (TCA_Kernel_Onto)—representing concepts at the very abstract level to easily categorize and integrate diversified knowledge in the domain of infrastructure management. (vi) Extend Trans_Dom_Kernel_Onto and TCA_Kernel_Onto to develop Transaction Domain Extended Ontology (Trans_Dom_Extended_Onto) and Tangible Capital Asset Extended Ontology (TCA_Extended_Onto)—abstract concepts represented in the kernel ontologies are extended to develop detailed taxonomies. (vii) Capture ontology—represents explicit declaration of the concepts in terms of soft and hard axioms. (viii) Code ontology—the knowledge represented in both the ontologies was formally coded using Protégé Ontology Editor (Protégé, 2014). (ix) Evaluate ontology—the knowledge represented in both the ontologies was verified using Protégé Ontology Editor and competency questions, and validated through industry experts. (x) Document ontology—the knowledge was finally documented for future use. Methodology to develop the protocol—the proposed TFP was developed using a four-step methodology devised based on the approach formulated by Adesola and Baines (2005) for the development of business process improvement methodologies. The approach involves reviewing and analyzing current frameworks/methodologies and then selecting the relevant candidates based on the key selection criteria. These steps include: (i) select the candidate standards; (ii) benchmark existing standards; (iii) link and build on existing standards; and (iv) develop the proposed TFP. 4 ONTOLOGY-SUPPORTED TRANSACTION FORMALISM PROTOCOL The development of the proposed ontology-supported TFP includes two parts: development of ontologies and development of the protocol.  4.1 Ontology Development  4.1.1 Transaction Domain Ontology To support the design, implementation, and management of transactions in the domain of infrastructure management, the Trans_Dom_Onto was developed. The knowledge represented in the ontology was organized according to the core and support concepts totaling to about 420. The core concepts represent the core building blocks of the transaction domain knowledge in the area of infrastructure management. The core concepts are: transaction, message, actor/actor-role, and information. The transaction is the complete communication between two parties. The message or message template represents the information that is required to be exchanged in a given transaction between the actor-roles. Actors are either organizations or individual that plays a specific role (i.e. sender or receiver) in a given transaction. The information is the discrete processed data that the actor-roles need to exchange to accomplish a transaction successfully. Detailed taxonomies of the core concepts were developed based on the concept of modality (i.e. a specific view of the concept categorization) while the explicit declaration of each concept is presented in Zeb and Froese (2012).  On the other hand, the support concepts support or assist in modelling the core transaction domain knowledge and is the focus of this paper. The support concepts encompass modality, attribute, mechanism, constraint, axiom, and relationship. The modality is a “characteristic that describes a thing and denotes it’s belonging to a particular group or category”, (El-Gohary, 2008).  According to Osman (2007), an attribute is a characteristic, feature, or property that describes a thing, entity, or concept. The transaction has five transaction attributes. Transaction function attribute—is a characteristic that describes a transaction based upon the function it performs in a given communication. Transaction dependency attribute—is a characteristic that describes a transaction based on the logical, 247-4 geographic, and cyber dependencies. Dependencies govern the design and implementation of transactions in practical scenarios. Transaction performance attribute—is a property that describes the performance of a transaction in terms of transaction efficiency. Transaction cost attribute—is a property that describes the transaction design, implementation, and operational cost. Transaction control attribute—is a characteristic that describes the transaction security in terms of transaction authorization.  According to El-Gohary (2008) and Osman (2007), the mechanism is an umbrella concept that has three sub-classes: guide, method, and measure, which includes all the tools and means required to accomplish a transaction successfully. The guide is a basic information or instructions needed to support the work of an actor role in all communications. It has the following four sub-classes: theory, best practice, strategy, and algorithm. The method is a generic concept that covers all such means, mediums, and techniques used to exchange and store transactions. In the Trans_Dom_Onto, methods for transaction transmission and transaction archiving are represented. According to Osman (2007), the measure is an abstract concept used to gauge conformance of an entity’s attribute to a pre-defined requirement as prescribed by specifications and codes. It has two types: test and metric. The test is used to measure conformance of the characteristics of a physical entity to the desired specification and code requirements. The metric is used to gauge conformance of the attribute of an abstract entity with respect to predefined requirements. The metric for the transaction (abstract entity) efficiency (attribute) is represented in the Trans_Dom_Onto. Objective metric—captures quantitative measurement of the transaction efficiency. It has two sub-classes: transaction cost savings and transaction time savings. Subjective metric—captures qualitative measurement of the transaction efficiency. The quality of a transaction is measured in terms of user convenience (Zott et al., 2000) and transaction righteousness.  The transaction is controlled by a set of transaction constraints, which refer to the conditions, factors, requirements, and obligations that restrict the way transactions are to be designed, implemented, and managed in the domain of infrastructure management. It has two sub-classes: internal and external constraints. The internal constraints are the requirements and obligations of the collaboration partners in a given transaction. It is categorized into two sub-classes: user requirement and contractual constraints. The external constraints are those constraints that are beyond the control of the collaboration partners. It has two sub-classes: regulatory and environmental constraints. According to (Osman, 2007 and El-Gohary, 2008), axiom unambiguously defines the concept represented in the ontology and constrain its interpretation. According to Gruninger and Fox (1995), axiom specifies unambiguous definitions of the concepts in a specific domain. The transaction axioms were classified as soft and hard axioms. The soft axioms define the concepts in plain English Language, whereas the hard axioms explicitly define the concepts using a formal language—Ontology Web Language (OWL) based Description Logic Syntax (DL). The hard axioms are of three types. Subsumption axiom—explicitly defines classes in hierarchies with parent-child relationship. Disjoint axiom—explicitly describes that the concepts are disjointed from each other, which mean an individual as a member of class “x” cannot be an instance of another class. Property restriction axiom—According to Horridge (2009), properties describe the binary relationship between the concepts, whereas the datatype properties describe the relationships between the individuals and data values, where individuals in OWL represent the instances of a class. In OWL, classes are defined in terms of the property restrictions, which states that “a restriction describes a class of individuals based on the relationships that members of the class participate in” (Horrdige, 2009), and therefore, a property restriction represents a class of individuals. The property restrictions are of three types: quantifier restriction (i.e. existential and universal), cardinality restriction (i.e. minimum, maximum, and exact), and has value restriction. A total 1726 axioms were defined in the Trans_Dom_Onto. According to Osman (2007), relationships are the associations between the concepts to enrich knowledge representation. It has the following two types. The hierarchal relationships include the generalization-specialization and aggregation-composition relationships. The generalization-specialization relationships —represent is-a or type-of or parent-child relationship between concepts and has two types: hyponymy and hypernymy, (El-Gohary, 2008). The aggregation-composition relationships—are whole-part relationships that represent the relationship between the whole and its parts, which is also known as partonymy (El-Gohary, 2008). It has two sub-classes: aggregation and composition relationships which 247-5 are further classified as meronymy and holonymy. The association or directed association represents other than “is-a” or “part-of” relationships in a knowledge representation. It has the 13 sub-classes: formalize, characteristic, restrict, devise, human function, relational, communicate, reveal, facilitate, cumulate, partake, ingest, and consequence relationship.    4.1.2 Tangible Capital Asset Ontology Development To support the design of message templates for the AI&CAR/TCA Reporting, the TCA_Onto was developed. The message templates represent header (meta information, e.g. name, from, to, etc.) and payload information (actual information content that actor-roles requires in a given transaction). The header information was captured from Trans_Dom_Onto and the payload information was captured from the TCA_Onto. The knowledge in the TCA_Onto was organized from four different perspectives or modalities. The individual asset represents the TCAs based on the type of the individual asset. According to PSAB (2009) and TCA (2012), individual asset has eight sub-classes: land, land improvement, building, building improvement, infrastructure, machinery and equipment, vehicle, and work in progress. The function based asset includes the TCAs based on the function they perform. Osman (2007) defined six such functions: control, access, protection, measuring, storage and conveyance assets. Commuting and processing was defined as part of this research work. The composition based asset represents the TCAs based on their aggregation in a given infrastructure system. For instance, system, sub-system, and component level (Osman, 2007). The sector based asset classifies the TCAs based on the sector to which they belong. It has two sub-classes: facility and infrastructure sector assets. The infrastructure sector asset has seven sub-classes: transportation, water, wastewater, solid waste management, gas, electricity, and telecom sector assets. The facility and infrastructure sector assets; specifically, the transportation, water, wastewater and solid waste management sector assets were further specialized and extended to develop detailed taxonomies as presented in Zeb and Froese (2014). Development of the detailed taxonomies of the gas, electricity, and telecom sector assets was omitted as these assets are generally not owned and operated by municipal infrastructure organizations and was covered in other existing ontologies. The TCA_Onto represents 345 classes of various TCAs in the facility and four infrastructure sectors. In addition, 1517 axioms were developed to explicitly describe TCAs in the domain of infrastructure management.     4.2 Development of the Transaction Formalism Protocol The proposed TFP protocol is an eight-step procedure developed to define transactions in the domain of infrastructure management effectively and efficiently. The protocol was developed from two perspectives; TFP Specification and TFP Tool. The TFP Specification was developed from a conceptual perspective where each step of the protocol was modeled as a distinct function for which inputs, controls, mechanisms, tools/techniques, and outputs were defined. The TFP Specification was developed using the IDEF0 modeling technique. The TFP Specification provides the formal “instruction set” for creating transaction specifications as presented in Zeb and Froese (2013). On the other hand, the proposed TFP Tool includes a set of Excel-based forms and some guidance that the transaction development personnel can use to define transaction specifications. These steps are: assess needs—step 1, define As-is transaction map (TM)—step 2, develop To-be TM—step 3, collect information—step 4, design message template (MT)—step 5, review TM and MT—step 6, adopt and implement TM and MT—step 7, and monitor transaction specification—step 8. The forms for the Tool were developed in step 1, 2, 3, 4, 6, and 8. The forms were developed to capture information easily, accurately, and consistently while defining transactions. For step 5 and 7, only guidance was provided on how to perform these steps because no data is required to be captured in these steps. A brief description of these steps is as follows.  • Step 1—a comprehensive needs assessment is conducted to identify and select among a set of transactions that has the greatest potential for IT improvement. The assessment criteria include: manual/paper based transaction, criticality, frequency, importance, likelihood of the management, cost of the transaction, and contractual and regulatory requirements.  • Step 2—a preliminary As-is TM is developed based on the needs assessment.  247-6 • Step 3—a To-be TM is developed that is an improved version of the As-is TM incorporating process, information, and mode improvements.  • Step 4—required header and payload information is collected in this step.  • Step 5—based on the collected information, MTs are defined.  • Step 6—the designed TMs and MTs are reviewed for errors; if any, and make changes before implementation.  • Step 7—the designed TMs and MTs are implemented in the Asset Information Integrator System.  • Step 8—the implemented transaction specifications are monitored for continuous improvements.  5 APPLICATION AREA AND ASSET INFORMATION INTEGRATOR SYSTEM The proposed TFP Tool was applied to one of the transactions identified through an IT survey (Zeb and Froese, 2012) conducted as part of this research work—AI&CAR/TCA Reporting. The municipal experts completed the needs assessment form using the above-mentioned criteria. The AI&CAR/TCA Reporting transaction was selected because it scored high against the assessment criterion. Despite the fact that the frequency of this transaction is not high, the municipal experts identified it as one of the potential transactions due to three reasons. Compliance with regulatory requirements—newly imposed regulatory requirements require municipalities to report asset inventory information in compliance with the Public Sector Accounting Board reporting requirements-3150 (PSAB, 2008) and condition assessment in compliance with the Statement of Recommended Practices, SORP reporting requirements (SORP, 2008). Manual/paper based transaction—currently, this transaction is manual as human interpretation of the information is required and organizations find it difficult and time consuming to compile, extract, and compare the TCA information. Costly—this transaction is costly in terms of time spent in extracting and comparing information.  The AI&CAR/TCA Reporting is a communication process in which different municipalities report their AI&CAR/TCA information to the provincial government for financial planning and funds allocation. The provincial government collects and analyzes this information to: (i) understand the long-term funding needs of different municipalities for infrastructure management; (ii) develop a consistent and planned approach to fund allocation; and (iii) to present the case to the federal government for additional funding, if required. This reporting also helps municipalities to update asset data on a regular basis, resulting in better management of their infrastructure systems. The AI&CAR/TCA Reporting case study transaction was used in two ways. First, the TFP Tool was applied to formalize this transaction to develop the transaction specification for the application area. Second, the transaction specification for AI&CAR/TCA Reporting was implemented to develop the prototype system—the AIIS.     The proposed AIIS was developed for the reporting of the AI&CAR/TCA information between the municipal and provincial government. Presently, the municipal organizations exchange this information in a manual and ad hoc way in the form of a PDF or Word file due to heterogeneous and inconsistent data formats. To transform to a more computer-based exchange of the TCA information, the AIIS implemented standardized MTs that were defined based on the knowledge represented in the two ontologies developed as part of this research work.  The proposed AIIS is a web-based prototype system that was implemented using the SharePoint platform. This platform was adopted due to its robustness and ease of use (Microsoft, 2012). The proposed AIIS collects the TCA reports received from various municipalities via standardized MTs, as shown in Figure 1, and integrate them with back-end applications (MS Excel, Excel Services within SharePoint, SharePoint Reporting Services, etc.) for further processing and analysis.  247-7   Figure 1:   Asset information integrator system 6 EVALUATION The ontology-supported TFP is composed of two parts and; therefore, the evaluation was separately conducted for each part: ontology and protocol. Ontology evaluation—both the Trans_Dom_Onto and TCA_Onto were evaluated through industry experts using a criteria-based approach (Gomez-Perez, 2001).  The criteria used to validate both the ontologies include: completeness (Gomez-Perez, 1996), correctness (Guarino, 1998), and clarity (Gruber, 1995 and Yu et al., 2007). Clarity judges the level to which a knowledge representation is clear and understandable. The class description communication error was used measure clarity of these ontologies. Completeness judges the level to which a knowledge representation is incomplete. Completeness is measured in terms of incompleteness. Correctness measure accuracy of the knowledge representation from a real-world perspective. The identity error was used to measure the correctness of both the ontologies. The Trans_Dom_Onto was validated through three domain experts using a structured interview approach. Each of them had more than 15 years of experience in different civil engineering fields. They were extremely familiar with the transportation sector while moderately familiar with the water, wastewater, and solid waste management sector. In addition, they were moderately familiar with the data or information modeling and the process of communication formalization. Similarly, the TCA_Onto was validated through three experts. Each of the experts had more than 15 years of experience in managing different types of infrastructure systems. They were extremely familiar with different infrastructure systems being owned, operated, or managed by municipalities. They were moderately familiar with data or information modeling and TCA reporting under PSAB-3150 reporting requirements. Two separate structured questionnaires were presented to the respondents wherein questions were organized according to three assessment criteria: clarity, completeness, and correctness. For each question, a multi-sheet table was developed to reflect various concepts in rows and respondents’ responses in the columns. The respondents were asked to rate a given concept on a scale of 1 (strongly disagree) to 5 (strongly agree) under each of the three assessment criteria. The responses were recorded for each concept reflected in the tables developed for clarity, completeness, and correctness, and an average score was calculated. In both ontologies, the average score ranged from 4 (agree) to 5 (strongly agree), which indicates that all the respondents were in universal agreement on the clarity, completeness, and correctness of the knowledge represented in the Trans_Dom_Onto and TCA_Onto.  Protocol evaluation—the proposed TFP Tool was validated through experts using a criteria based approach. Adesola and Baines (2005) identified three criteria: feasibility, usability, and usefulness to validate an improvement methodology, which were adopted with modifications to validate the proposed TFP Tool. An additional criterion—generalizability—was also identified, defined, and used to validate the TFP Tool. Feasibility assesses the appropriateness of the TFP Tool in terms of completeness, correctness, and reasonableness. Usability assesses the ability to learn and work with the TFP Tool, which was evaluated using three measures: understandability, applicability, and guidance/supportability. 247-8 Usefulness assesses the utility and value of the tool in terms of five measures: effectiveness, efficiency, consistency, changeability/adaptability/customizability, and reusability. Finally, generalizability assesses the applicability of the Tool across a wide variety of communications within AEC/FM and non-AEC/FM industries, using a single measure of generality. A set of questions was framed under each criteria. The experts answers were recorded on an agreement continuum rating system: unable to rate (0), strongly disagree (1), disagree (2), neither agree nor disagree (3), agree (4), and strongly agree (5). Answers were recorded for each question given under feasibility, usability, usefulness and generalizability and  average scores were calculated. The resulting average scores ranged from 4 (agree) to 4.8~5 (strongly agree), indicating that the proposed TFP Tool was feasible, usable, useful, and generic.     7 CONCLUSIONS Presently, data exchange in the domain of infrastructure is performed on a manual and ad hoc basis. The growing trend is to transform this manual data exchange to a more formalized computer-to-computer based exchange of information. To accomplish the paradigm shift, an ontology-supported TFP was developed. The proposed protocol consisted of two parts: ontologies and protocol. To support the design, implementation, and management of transactions in the domain of infrastructure management, two ontologies were developed: the Trans_Dom_Onto and TCA_Onto. Also, the protocol—an eight-step procedure was developed at two levels of abstraction: TFP Specification and TFP Tool. The TFP Specification is a conceptual model that makes a foundation for the TFP Tool. On the other hand, the TFP Tool includes a set of forms and guidance developed for specific steps of the protocol. The TFP Tool was applied in the domain of infrastructure management to develop transaction specifications for the AI&CAR/TCA Reporting, which was implemented in an AIIS. Both the ontologies and protocol were validated through industry experts using criteria based approach. The evaluation results indicate that the transaction development personnel (i.e. transaction analyst, process modellers, software developers, industry experts, and users) can use the protocol effectively and efficiently.     Acknowledgements The authors gratefully acknowledge the Canadian Natural Sciences and Engineering Research Council (NSERC) for their support to this research. References Adesola, S. and Baines, T. 2005. Developing and Evaluating a Methodology for Business Process Improvement. Business Process Management Journal, 11(1): 37-46, Emerald Group Publishing Ltd. Berard, O. and Karlshoej, J. 2012. Information Delivery Manuals to Integrate Building Product Information into Design. Journal of Information Technology in Construction, 17: 64-74. El-Gohary, N. 2008. Semantic Process Modeling and Integration for Collaborative Construction and Infrastructure Development. Ph.D. Thesis, Department of Civil Engineering, University of Toronto. Felio, G. 2012. Canadian Infrastructure Report Card”, Municipal Roads and Water Systems. Vol. 1. Sponsored by Canadian Construction Association, Canadian Society for Civil Engineering, Canadian Public Works Association, and Federation of Canadian Municipalities. Fernández López, M.; Gómez-Pérez, A.; and Juristo N. 1997. METHONTOLOGY: From Ontological Art to Ontological Engineering. Spring Symposium on Ontological Engineering of AAAI, Stanford University, California, USA, pp. 33-40.  Froese, T. 2007. agcXML Generic Document Distribution Use Case. buildingSMART Alliance, National Institute of Building Sciences, USA.  Gómez-Pérez, A. 2001. Evaluation of Ontologies. Intl. Journal of Intelligent Systems, 16: 391–409. Gruber, T.R. 1995. Towards Principles for the Design of Ontologies Used for Knowledge Sharing. International Journal Human-Computer Studies, Academic Press Limited, 43: 907-928. Gruninger, M. and Fox, M.S. 1995. Methodology for the Design and Evaluation of Ontologies. Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal, Canada. Guarino, N. 1998. Some Ontological Principles for Designing Upper Level Lexical Resources. In Proceedings of the 1st International Conference on Lexical Resources and Evaluation. Horridge, M. 2009. A Practical Guide to Building Ontologies Using Protégé 4 and CO-ODE Tools. The University of Manchester, Edition 1.2. 247-9 IAI-IDM. 2012. Building Information Models-Information Delivery Manual, Part 2: Interaction Framework. International Standard, ISO 29481-2, 1st Edition, ISO, pp. 1-74. IAI-MVD. 2005. Model View Definition. International Alliance of Interoperability, buildingSMART International, IFC Solution Factory. Noy, N.F. and McGuinness, D.L. 2001. Ontology Development 101: A Guide to Creating Your First Ontology. Technical Report, KSL-01-05, Knowledge Systems, AI Laboratory, Stanford University, USA. Osman, H.M. 2007. A Knowledge-Enabled System for Routing Urban Utility Infrastructure. Ph.D. Thesis, Department of Civil Engineering, University of Toronto. Protégé. 2014. Welcome to Protégé. National Resource for Biomedical Ontologies and Knowledge, Stanford Center for Biomedical Informatics Research, School of Medicine, Stanford University. PSAB. 2008. Canadian Institute of Chartered Accountants (CICA) Public Sector Accounting Handbook. Canadian Institute of Chartered Accountants, Toronto, Canada. PSAB. 2009. Guide to Accounting and Reporting of Tangible Capital Assets. Public Sector Accounting Board (PSAB), Canadian Institute of Chartered Accountants (CICA), Toronto, Ontario, Canada. Schaap, H.A.; Bouwman, J.W.; and Willems, P.H. 2008. The COINS Systems. Concept Publication, CUR-Report 208-3, CUR Construction and Infrastructure.   SORP. 2008. Draft Statement of Recommended Practices: Assessment of Tangible Capital Assets. Public Sector Accounting Board (PSAB), Toronto, Canada. Stewart, M.A. 2010. Canadian Geospatial Data Infrastructure Information Product 13. GeoConnections Geospatial Returns on Investment Case Study: Multi-Agency Situational Awareness System (MASAS), Developed by New Brunswick Emergency Measures Organization, NRC, Canada. TCA. 2012. School Board and School Authority Tangible Capital Assets. Provincial Accounting Policies and Implementation Guide, Release No. 9. Ministry of Education, Ontario, Canada.  Uschold, M. and Gruninger, M. 1996. Ontologies: Principles, Methods and Applications. Knowledge Engineering Review, AIAI-TR-191, Vol. 11. VISI, 2011. VISI System Guideline Version 1.3. Main Document Normative, Document Version 1, Status Definitive, Developed by CROW. Yu, J.; Thom, J.A.; and Tam, A. 2007. Ontology Evaluation Using Wikipedia Categories for Browsing. Proc. of the 16th ACM Conf. on Information & Knowledge Management, Lisbon, Portugal, pp. 223–232. Zeb, J. and Froese, T. 2011. Design and Management of Transactions in the AEC/FM Industry Using an Ontological Approach. 3rd Intl./9th Construction Specialty Conference, Ottawa, CSCE, pp. 1-10. Zeb, J. and Froese, T. 2012. Transaction Ontology in the Domain of Infrastructure Management. Canadian Journal of Civil Engineering, 39(9): 1-12, Published by NRC Research Press.  Zeb, J. and Froese, T. 2014. An Ontology of Tangible Capital Assets in Infrastructure Management. Infrastructure Asset Management Journal, 1(3): 81-92, Institution of Civil Engineers, UK. Zeb, J. and Froese, T. 2014. Infrastructure Management Transaction Formalism Protocol Specification: A Process Development Model. Construction Innovation: Information, Process, Management Journal, 14(1): 69-87, Emerald Group Publishing Limited.  Zeb, J.; Froese, T.; and Vanier, D. 2012. State-of-the-Art Information Technology Use for Municipal Infrastructure Management. Journal of Information Technology in Construction, 17: 179-193. Zhang, J. and El-Diraby, T. E. 2009. SSWP: A Social Semantic Web Portal for Effective Communication in Construction. Journal of Computers, Academy Publisher, 4(4): 330-337. Zhu, Y. 2007. agcXML Technical Framework (v 0.6). buildingSMART Alliance, National Institute of Building Sciences, USA. Zott, C.; Amit, R.; and Donlevy, J. 2000. Strategies for Value Creation in e-Commerce: Best Practice in Europe. European Management Journal, 5(18): 463-475. 247-10  5th International/11th Construction Specialty Conference 5e International/11e Conférence spécialisée sur la construction    Vancouver, British Columbia June 8 to June 10, 2015 / 8 juin au 10 juin 2015   AN ONTOLOGY-SUPPORTED TRANSACTION FORMALISM PROTOCOL IN INFRASTRUCTURE MANAGEMENT Jehan Zeb1 and Thomas Froese1  1 Department of Civil Engineering, University of British Columbia, Vancouver, Canada Abstract: Infrastructure organizations use diversified information systems to exchange data (transaction). Presently, data exchange in the area of infrastructure management is accomplished in a manual and ad hoc basis. The growing trend is to transform these manual data exchanges to a computer-to-computer based exchange of information. “How to formalize these data exchanges or transactions?” is the core research question, which was dealt with developing and applying an ontology-supported Transaction Formalism Protocol (TFP). The proposed solution is composed of two parts: ontology and protocol. Two ontologies, the Transaction Domain Ontology and Tangible Capital Asset ontology, were developed using an eleven-step methodology to represent transaction knowledge and Tangible Capital Asset knowledge respectively to support the design and implementation of transactions in infrastructure management. The proposed TFP is an eight-step procedure developed using a four-step methodology from two perspectives: the TFP Specification modelled each step of the protocol as a function for which inputs, controls, mechanisms, tools/techniques, and outputs were defined, whereas the TFP Tool includes a set of forms and guidance developed for specific steps of the protocol.  The TFP was applied to develop transaction specifications for the Asset Inventory and Condition Assessment Reporting/Tangible Capital Asset (AI&CAR/TCA) Reporting, which was implemented in the Asset Information Integrator System for the exchange of Tangible Capital Asset information between the municipal and provincial governments. The main contributions of this research work include the development of the two ontologies, protocol, and Asset Integrator Information System.   1 INTRODUCTION Infrastructure agencies, including shallow utilities own, operate, and manage infrastructure systems using a wide range of information systems, each based on different proprietary data models. Various agencies and utilities interact with each other and exchange infrastructure information to accomplish a wide range of collaborative tasks. As infrastructure agencies increasingly rely on computer-based systems to manage infrastructure data, much of the information that was traditionally exchanged using manual and ad hoc communications can now be exchanged electronically through computer-to-computer data exchange. This allows for more extensive, rapid, and error-free exchange of information, but it requires more formal specifications to govern these data exchanges (i.e. transactions). A transaction is defined “as any communication or interaction between the sender and receiver roles that make up the information flow through a single or collection of a sequenced set of messages” (Zeb and Froese, 2012). Transaction example includes: communications during a disaster response (“Is power available in this area?” “Who is responsible for this section of roadway?” “When will water to be restored to this area?”); coordination between buried utility agencies; aggregation of data from multiple infrastructure management software with regards to the asset inventory and condition assessment reporting and formalized transactions used in the multi-agency situational awareness system wherein the provincial government requires information 247-1 from many other organizations outside the provincial jurisdiction to prepare for and mitigate the impacts of emergency incidents (Stewart, 2010). Although the inevitable trend in the communication technology is towards increasing computerization, which requires transaction formalization, but there are many challenges that prevent this formalization from being an easy or efficient process. These challenges include: lack of an appropriate process for carrying out this formalization; heterogeneity in data formats, data (class) definitions, and data aggregation (Felio, 2012). These issues were dealt with developing an ontology-supported Transaction Formalism Protocol (TFP) in the domain of infrastructure management.  The TFP is a procedure developed to formalize transactions and create transaction specifications effectively and efficiently. To support the development and application of the TFP, two ontologies were built: the Transaction Domain Ontology (Trans_Dom_Onto), and the Tangible Capital Asset Ontology (TCA_Onto). According to Gruber (1995), an ontology is a “formal explicit specification of a shared conceptualization.” The Trans_Dom_Onto represents transaction related knowledge to support the design, management, implementation of transactions, and development of the TFP. The TCA_Onto represents the Tangible Capital Assets (TCAs) to support the design of message templates in a neutral data format to address message-based interoperability between information systems of the infrastructure organizations. According to PSAB (2009), the TCAs are “non-financial assets having physical substance that are acquired, constructed, or developed and: are held for use in the production or supply of goods and services; have useful lives extending beyond an accounting period; are intended to be used on a continuing basis, and are not intended for sale in the ordinary course of operations.”   The proposed TFP protocol is an eight-step procedure that was developed from two different perspectives. The TFP Specification represents each step of the protocol as a distinct function for which inputs, controls, mechanisms, tools/techniques, and outputs were defined. The TFP Tool is comprised of a set of Excel-based forms and guidance developed for specific steps of the protocol that the transaction development personnel can use to define transaction specifications for IT based solutions.  The proposed TFP was applied to develop transaction specifications for the Asset Inventory (PSAB, 2008) and Condition Assessment (SORP, 2008) Reporting/Tangible Capital Asset (AI&CAR/TCA) Reporting. The formalized transaction specification was implemented in a prototype Asset Information Integrator System (AIIS). The prototype system collects, stores, visualizes, and analyzes the asset inventory and condition assessment information received from different municipalities to help the provincial government to: understand long-term financial needs of municipalities for infrastructure management; develop a consistent and planned approach for funds allocation; and present the case to the federal government for additional funding, if required. This paper is divided into the following seven sections. Background information and related literature are discussed in section 1 and 2 respectively. Section 3 describes the methodology used, whereas section 4 briefly explains the development of the ontologies and TFP. Application of the TFP is presented in section 5 and evaluation is elucidated in section 6. Conclusions and contributions are discussed in section 7.  2 LITERATURE REVIEW  The literature review is discussed from two perspectives: ontologies in the domain of infrastructure management and related work process and communication formalization standards and methodologies. Ontologies in infrastructure management—three ontologies in the domain of infrastructure management are of particular importance: Infrastructure Product Ontology, IPD-Onto (Osman, 2007); Infrastructure and Construction Process Ontology, IC-Pro-Onto (El-Gohary, 2008); and Actor Ontology, Actor-Onto (Zhang and El-Diraby, 2009). The IPD–Onto  (Osman, 2007) represents infrastructure product knowledge (e.g. pipe, valve, pump, etc.). The IC-Pro-Onto represents process knowledge, e.g. core design and construction processes, management processes, knowledge integration processes, and support processes (El-Gohary, 2008). The Actor-Onto represents knowledge related to various actors and actor-roles in the construction industry (Zhang and El-Diraby, 2009). While these three core formalism 247-2 dimensions have been completed, there remains a need to formalize information exchange processes (transactions) to enable computer-to-computer, message-based exchange of information. Transaction formalism involves specifying and defining not only the process, actor and infrastructure system information, but also the specification of information exchange details, which is to be addressed through the development of the Transaction Domain Ontology (Trans_Dom_Onto). In addition, these ontologies do not completely support the design of the message templates that are required to be exchanged in the AI&CAR/TCA Reporting (information transaction). The IPD-Onto doesn’t represent a complete set of the infrastructure products, and it was extended in this research in terms of the TCAs to provide payload information for the design of the message templates for the AI&CAR/TCA Reporting, which led to the development of the TCA_Onto. The header information in these message templates, meanwhile, was captured from the Trans_Dom_Onto that was developed as part of this research work.  State-of-the-art standards—some process and communication formalization techniques currently exist in the Architecture, Engineering, Construction and Facilities Management (AEC/FM) industries, but these standards do not fully address the requirements for transaction formalism in the domain of infrastructure management. In the AEC/FM industries, the Information Delivery Manual (IDM) formalizes work processes in the construction industry (IAI-IDM, 2012). It is a requirement specification methodology focusing on model-based exchange of information between different parties using building information models (BIM). The IDM defines information in terms of informational elements (objects and their attributes) rather than informational products (documents), hence the methodology is BIM specific. In addition, the exhaustive nature of the IDM makes it time-consuming to develop and difficult to share with others on projects (Berard and Karlshoej, 2012). Because of the IDM’s explicit focus on BIM, it does not meet the requirements for a general communication formalism technique for the infrastructure sector, but it is a very relevant exemplar for this research work, and therefore, some features of the IDM specifications were adopted with modifications. The Model View Definition (MVD) is a methodology developed to formally define a subset of an Industry Foundation Class (IFC) BIM model (IAI-MVD, 2005). The MVD is relevant since it is typically used to formally specify the particular BIM information to be exchanged during a specific type of data transaction, but again, it is BIM specific and it lacks a step-by-step procedure describing how to capture requirements. The Voorwaarden Scheppen Voor Invoering Standaardisatie (VISI), which means “Terms and Conditions for the Implementation of Standardization in ICT” is a Dutch communication management standard developed to define transactions in the AEC/FM industry (VISI, 2011). The VISI standard lacks a step-by-step process to capture transaction requirements and define transactions, and it depends on an Extensible Markup Language (XML) based model representing information in a local context (i.e. the Dutch construction industry). A related standard, the Construction Objects and Integration of Processes and Systems Engineering Method (COINS-EM/CEM), is a Dutch standard developed to create agreements on working methods and organization of production processes and information (Schaap et al., 2008). As with the IDM, COINS-EM/CEM focuses on exchange of model-based/3D object data rather than communication in general, and it also lacks a systematic procedure for requirement specification. Another initiative, the agcXML, focused on developing a set of XML schemas to enable industry experts to exchange electronic building information reliably and efficiently between heterogeneous proprietary software applications to improve interoperability and integration of the information systems (Zhu, 2007). The agcXML doesn’t include a general data transaction specification, it does include a format for transaction use cases and a use case for generic document distribution (Froese, 2007), but does not include a procedure for transaction design.  In summary, none of the standards discussed above fully meet all of the objectives of this research work in terms of developing a step-by-step procedure to define transaction specifications in the domain of infrastructure management. Most of the standards are work-process-centric rather than communication-centric. Most do not address how to assess needs and capture information that is required in a given communication. Most of the standards are IT-expert-centric and are not suitable for the end users. These shortcomings led to the development of the proposed ontology-supported TFP.  3 METHODOLOGY Methodology to develop ontologies—a ten-step methodology was devised to build the Trans_Dom_Onto and TCA_Onto, which was a hybrid version of the various approaches developed by Fernandez-Lopez et 247-3 al., (1997); Uschold and Gruininger (1996); and Noy and McGuinness (2001). (i) Define ontology coverage—purpose, use, and users of the ontologies are defined in this step. (ii) Capture competency questions—a set of competency questions were developed that the ontology should be able to answer. (iii) Generate/create taxonomy—a preliminary taxonomy of various concepts was developed. (iv) Reuse existing ontologies—as long as possible, use was made of the existing ontologies and relevant concepts were captured from existing ontologies. (v) Develop Transaction Domain Kernel Ontology, (Trans_Dom_Kernel_Onto) and Tangible Capital Asset Kernel Ontology, (TCA_Kernel_Onto)—representing concepts at the very abstract level to easily categorize and integrate diversified knowledge in the domain of infrastructure management. (vi) Extend Trans_Dom_Kernel_Onto and TCA_Kernel_Onto to develop Transaction Domain Extended Ontology (Trans_Dom_Extended_Onto) and Tangible Capital Asset Extended Ontology (TCA_Extended_Onto)—abstract concepts represented in the kernel ontologies are extended to develop detailed taxonomies. (vii) Capture ontology—represents explicit declaration of the concepts in terms of soft and hard axioms. (viii) Code ontology—the knowledge represented in both the ontologies was formally coded using Protégé Ontology Editor (Protégé, 2014). (ix) Evaluate ontology—the knowledge represented in both the ontologies was verified using Protégé Ontology Editor and competency questions, and validated through industry experts. (x) Document ontology—the knowledge was finally documented for future use. Methodology to develop the protocol—the proposed TFP was developed using a four-step methodology devised based on the approach formulated by Adesola and Baines (2005) for the development of business process improvement methodologies. The approach involves reviewing and analyzing current frameworks/methodologies and then selecting the relevant candidates based on the key selection criteria. These steps include: (i) select the candidate standards; (ii) benchmark existing standards; (iii) link and build on existing standards; and (iv) develop the proposed TFP. 4 ONTOLOGY-SUPPORTED TRANSACTION FORMALISM PROTOCOL The development of the proposed ontology-supported TFP includes two parts: development of ontologies and development of the protocol.  4.1 Ontology Development  4.1.1 Transaction Domain Ontology To support the design, implementation, and management of transactions in the domain of infrastructure management, the Trans_Dom_Onto was developed. The knowledge represented in the ontology was organized according to the core and support concepts totaling to about 420. The core concepts represent the core building blocks of the transaction domain knowledge in the area of infrastructure management. The core concepts are: transaction, message, actor/actor-role, and information. The transaction is the complete communication between two parties. The message or message template represents the information that is required to be exchanged in a given transaction between the actor-roles. Actors are either organizations or individual that plays a specific role (i.e. sender or receiver) in a given transaction. The information is the discrete processed data that the actor-roles need to exchange to accomplish a transaction successfully. Detailed taxonomies of the core concepts were developed based on the concept of modality (i.e. a specific view of the concept categorization) while the explicit declaration of each concept is presented in Zeb and Froese (2012).  On the other hand, the support concepts support or assist in modelling the core transaction domain knowledge and is the focus of this paper. The support concepts encompass modality, attribute, mechanism, constraint, axiom, and relationship. The modality is a “characteristic that describes a thing and denotes it’s belonging to a particular group or category”, (El-Gohary, 2008).  According to Osman (2007), an attribute is a characteristic, feature, or property that describes a thing, entity, or concept. The transaction has five transaction attributes. Transaction function attribute—is a characteristic that describes a transaction based upon the function it performs in a given communication. Transaction dependency attribute—is a characteristic that describes a transaction based on the logical, 247-4 geographic, and cyber dependencies. Dependencies govern the design and implementation of transactions in practical scenarios. Transaction performance attribute—is a property that describes the performance of a transaction in terms of transaction efficiency. Transaction cost attribute—is a property that describes the transaction design, implementation, and operational cost. Transaction control attribute—is a characteristic that describes the transaction security in terms of transaction authorization.  According to El-Gohary (2008) and Osman (2007), the mechanism is an umbrella concept that has three sub-classes: guide, method, and measure, which includes all the tools and means required to accomplish a transaction successfully. The guide is a basic information or instructions needed to support the work of an actor role in all communications. It has the following four sub-classes: theory, best practice, strategy, and algorithm. The method is a generic concept that covers all such means, mediums, and techniques used to exchange and store transactions. In the Trans_Dom_Onto, methods for transaction transmission and transaction archiving are represented. According to Osman (2007), the measure is an abstract concept used to gauge conformance of an entity’s attribute to a pre-defined requirement as prescribed by specifications and codes. It has two types: test and metric. The test is used to measure conformance of the characteristics of a physical entity to the desired specification and code requirements. The metric is used to gauge conformance of the attribute of an abstract entity with respect to predefined requirements. The metric for the transaction (abstract entity) efficiency (attribute) is represented in the Trans_Dom_Onto. Objective metric—captures quantitative measurement of the transaction efficiency. It has two sub-classes: transaction cost savings and transaction time savings. Subjective metric—captures qualitative measurement of the transaction efficiency. The quality of a transaction is measured in terms of user convenience (Zott et al., 2000) and transaction righteousness.  The transaction is controlled by a set of transaction constraints, which refer to the conditions, factors, requirements, and obligations that restrict the way transactions are to be designed, implemented, and managed in the domain of infrastructure management. It has two sub-classes: internal and external constraints. The internal constraints are the requirements and obligations of the collaboration partners in a given transaction. It is categorized into two sub-classes: user requirement and contractual constraints. The external constraints are those constraints that are beyond the control of the collaboration partners. It has two sub-classes: regulatory and environmental constraints. According to (Osman, 2007 and El-Gohary, 2008), axiom unambiguously defines the concept represented in the ontology and constrain its interpretation. According to Gruninger and Fox (1995), axiom specifies unambiguous definitions of the concepts in a specific domain. The transaction axioms were classified as soft and hard axioms. The soft axioms define the concepts in plain English Language, whereas the hard axioms explicitly define the concepts using a formal language—Ontology Web Language (OWL) based Description Logic Syntax (DL). The hard axioms are of three types. Subsumption axiom—explicitly defines classes in hierarchies with parent-child relationship. Disjoint axiom—explicitly describes that the concepts are disjointed from each other, which mean an individual as a member of class “x” cannot be an instance of another class. Property restriction axiom—According to Horridge (2009), properties describe the binary relationship between the concepts, whereas the datatype properties describe the relationships between the individuals and data values, where individuals in OWL represent the instances of a class. In OWL, classes are defined in terms of the property restrictions, which states that “a restriction describes a class of individuals based on the relationships that members of the class participate in” (Horrdige, 2009), and therefore, a property restriction represents a class of individuals. The property restrictions are of three types: quantifier restriction (i.e. existential and universal), cardinality restriction (i.e. minimum, maximum, and exact), and has value restriction. A total 1726 axioms were defined in the Trans_Dom_Onto. According to Osman (2007), relationships are the associations between the concepts to enrich knowledge representation. It has the following two types. The hierarchal relationships include the generalization-specialization and aggregation-composition relationships. The generalization-specialization relationships —represent is-a or type-of or parent-child relationship between concepts and has two types: hyponymy and hypernymy, (El-Gohary, 2008). The aggregation-composition relationships—are whole-part relationships that represent the relationship between the whole and its parts, which is also known as partonymy (El-Gohary, 2008). It has two sub-classes: aggregation and composition relationships which 247-5 are further classified as meronymy and holonymy. The association or directed association represents other than “is-a” or “part-of” relationships in a knowledge representation. It has the 13 sub-classes: formalize, characteristic, restrict, devise, human function, relational, communicate, reveal, facilitate, cumulate, partake, ingest, and consequence relationship.    4.1.2 Tangible Capital Asset Ontology Development To support the design of message templates for the AI&CAR/TCA Reporting, the TCA_Onto was developed. The message templates represent header (meta information, e.g. name, from, to, etc.) and payload information (actual information content that actor-roles requires in a given transaction). The header information was captured from Trans_Dom_Onto and the payload information was captured from the TCA_Onto. The knowledge in the TCA_Onto was organized from four different perspectives or modalities. The individual asset represents the TCAs based on the type of the individual asset. According to PSAB (2009) and TCA (2012), individual asset has eight sub-classes: land, land improvement, building, building improvement, infrastructure, machinery and equipment, vehicle, and work in progress. The function based asset includes the TCAs based on the function they perform. Osman (2007) defined six such functions: control, access, protection, measuring, storage and conveyance assets. Commuting and processing was defined as part of this research work. The composition based asset represents the TCAs based on their aggregation in a given infrastructure system. For instance, system, sub-system, and component level (Osman, 2007). The sector based asset classifies the TCAs based on the sector to which they belong. It has two sub-classes: facility and infrastructure sector assets. The infrastructure sector asset has seven sub-classes: transportation, water, wastewater, solid waste management, gas, electricity, and telecom sector assets. The facility and infrastructure sector assets; specifically, the transportation, water, wastewater and solid waste management sector assets were further specialized and extended to develop detailed taxonomies as presented in Zeb and Froese (2014). Development of the detailed taxonomies of the gas, electricity, and telecom sector assets was omitted as these assets are generally not owned and operated by municipal infrastructure organizations and was covered in other existing ontologies. The TCA_Onto represents 345 classes of various TCAs in the facility and four infrastructure sectors. In addition, 1517 axioms were developed to explicitly describe TCAs in the domain of infrastructure management.     4.2 Development of the Transaction Formalism Protocol The proposed TFP protocol is an eight-step procedure developed to define transactions in the domain of infrastructure management effectively and efficiently. The protocol was developed from two perspectives; TFP Specification and TFP Tool. The TFP Specification was developed from a conceptual perspective where each step of the protocol was modeled as a distinct function for which inputs, controls, mechanisms, tools/techniques, and outputs were defined. The TFP Specification was developed using the IDEF0 modeling technique. The TFP Specification provides the formal “instruction set” for creating transaction specifications as presented in Zeb and Froese (2013). On the other hand, the proposed TFP Tool includes a set of Excel-based forms and some guidance that the transaction development personnel can use to define transaction specifications. These steps are: assess needs—step 1, define As-is transaction map (TM)—step 2, develop To-be TM—step 3, collect information—step 4, design message template (MT)—step 5, review TM and MT—step 6, adopt and implement TM and MT—step 7, and monitor transaction specification—step 8. The forms for the Tool were developed in step 1, 2, 3, 4, 6, and 8. The forms were developed to capture information easily, accurately, and consistently while defining transactions. For step 5 and 7, only guidance was provided on how to perform these steps because no data is required to be captured in these steps. A brief description of these steps is as follows.  • Step 1—a comprehensive needs assessment is conducted to identify and select among a set of transactions that has the greatest potential for IT improvement. The assessment criteria include: manual/paper based transaction, criticality, frequency, importance, likelihood of the management, cost of the transaction, and contractual and regulatory requirements.  • Step 2—a preliminary As-is TM is developed based on the needs assessment.  247-6 • Step 3—a To-be TM is developed that is an improved version of the As-is TM incorporating process, information, and mode improvements.  • Step 4—required header and payload information is collected in this step.  • Step 5—based on the collected information, MTs are defined.  • Step 6—the designed TMs and MTs are reviewed for errors; if any, and make changes before implementation.  • Step 7—the designed TMs and MTs are implemented in the Asset Information Integrator System.  • Step 8—the implemented transaction specifications are monitored for continuous improvements.  5 APPLICATION AREA AND ASSET INFORMATION INTEGRATOR SYSTEM The proposed TFP Tool was applied to one of the transactions identified through an IT survey (Zeb and Froese, 2012) conducted as part of this research work—AI&CAR/TCA Reporting. The municipal experts completed the needs assessment form using the above-mentioned criteria. The AI&CAR/TCA Reporting transaction was selected because it scored high against the assessment criterion. Despite the fact that the frequency of this transaction is not high, the municipal experts identified it as one of the potential transactions due to three reasons. Compliance with regulatory requirements—newly imposed regulatory requirements require municipalities to report asset inventory information in compliance with the Public Sector Accounting Board reporting requirements-3150 (PSAB, 2008) and condition assessment in compliance with the Statement of Recommended Practices, SORP reporting requirements (SORP, 2008). Manual/paper based transaction—currently, this transaction is manual as human interpretation of the information is required and organizations find it difficult and time consuming to compile, extract, and compare the TCA information. Costly—this transaction is costly in terms of time spent in extracting and comparing information.  The AI&CAR/TCA Reporting is a communication process in which different municipalities report their AI&CAR/TCA information to the provincial government for financial planning and funds allocation. The provincial government collects and analyzes this information to: (i) understand the long-term funding needs of different municipalities for infrastructure management; (ii) develop a consistent and planned approach to fund allocation; and (iii) to present the case to the federal government for additional funding, if required. This reporting also helps municipalities to update asset data on a regular basis, resulting in better management of their infrastructure systems. The AI&CAR/TCA Reporting case study transaction was used in two ways. First, the TFP Tool was applied to formalize this transaction to develop the transaction specification for the application area. Second, the transaction specification for AI&CAR/TCA Reporting was implemented to develop the prototype system—the AIIS.     The proposed AIIS was developed for the reporting of the AI&CAR/TCA information between the municipal and provincial government. Presently, the municipal organizations exchange this information in a manual and ad hoc way in the form of a PDF or Word file due to heterogeneous and inconsistent data formats. To transform to a more computer-based exchange of the TCA information, the AIIS implemented standardized MTs that were defined based on the knowledge represented in the two ontologies developed as part of this research work.  The proposed AIIS is a web-based prototype system that was implemented using the SharePoint platform. This platform was adopted due to its robustness and ease of use (Microsoft, 2012). The proposed AIIS collects the TCA reports received from various municipalities via standardized MTs, as shown in Figure 1, and integrate them with back-end applications (MS Excel, Excel Services within SharePoint, SharePoint Reporting Services, etc.) for further processing and analysis.  247-7   Figure 1:   Asset information integrator system 6 EVALUATION The ontology-supported TFP is composed of two parts and; therefore, the evaluation was separately conducted for each part: ontology and protocol. Ontology evaluation—both the Trans_Dom_Onto and TCA_Onto were evaluated through industry experts using a criteria-based approach (Gomez-Perez, 2001).  The criteria used to validate both the ontologies include: completeness (Gomez-Perez, 1996), correctness (Guarino, 1998), and clarity (Gruber, 1995 and Yu et al., 2007). Clarity judges the level to which a knowledge representation is clear and understandable. The class description communication error was used measure clarity of these ontologies. Completeness judges the level to which a knowledge representation is incomplete. Completeness is measured in terms of incompleteness. Correctness measure accuracy of the knowledge representation from a real-world perspective. The identity error was used to measure the correctness of both the ontologies. The Trans_Dom_Onto was validated through three domain experts using a structured interview approach. Each of them had more than 15 years of experience in different civil engineering fields. They were extremely familiar with the transportation sector while moderately familiar with the water, wastewater, and solid waste management sector. In addition, they were moderately familiar with the data or information modeling and the process of communication formalization. Similarly, the TCA_Onto was validated through three experts. Each of the experts had more than 15 years of experience in managing different types of infrastructure systems. They were extremely familiar with different infrastructure systems being owned, operated, or managed by municipalities. They were moderately familiar with data or information modeling and TCA reporting under PSAB-3150 reporting requirements. Two separate structured questionnaires were presented to the respondents wherein questions were organized according to three assessment criteria: clarity, completeness, and correctness. For each question, a multi-sheet table was developed to reflect various concepts in rows and respondents’ responses in the columns. The respondents were asked to rate a given concept on a scale of 1 (strongly disagree) to 5 (strongly agree) under each of the three assessment criteria. The responses were recorded for each concept reflected in the tables developed for clarity, completeness, and correctness, and an average score was calculated. In both ontologies, the average score ranged from 4 (agree) to 5 (strongly agree), which indicates that all the respondents were in universal agreement on the clarity, completeness, and correctness of the knowledge represented in the Trans_Dom_Onto and TCA_Onto.  Protocol evaluation—the proposed TFP Tool was validated through experts using a criteria based approach. Adesola and Baines (2005) identified three criteria: feasibility, usability, and usefulness to validate an improvement methodology, which were adopted with modifications to validate the proposed TFP Tool. An additional criterion—generalizability—was also identified, defined, and used to validate the TFP Tool. Feasibility assesses the appropriateness of the TFP Tool in terms of completeness, correctness, and reasonableness. Usability assesses the ability to learn and work with the TFP Tool, which was evaluated using three measures: understandability, applicability, and guidance/supportability. 247-8 Usefulness assesses the utility and value of the tool in terms of five measures: effectiveness, efficiency, consistency, changeability/adaptability/customizability, and reusability. Finally, generalizability assesses the applicability of the Tool across a wide variety of communications within AEC/FM and non-AEC/FM industries, using a single measure of generality. A set of questions was framed under each criteria. The experts answers were recorded on an agreement continuum rating system: unable to rate (0), strongly disagree (1), disagree (2), neither agree nor disagree (3), agree (4), and strongly agree (5). Answers were recorded for each question given under feasibility, usability, usefulness and generalizability and  average scores were calculated. The resulting average scores ranged from 4 (agree) to 4.8~5 (strongly agree), indicating that the proposed TFP Tool was feasible, usable, useful, and generic.     7 CONCLUSIONS Presently, data exchange in the domain of infrastructure is performed on a manual and ad hoc basis. The growing trend is to transform this manual data exchange to a more formalized computer-to-computer based exchange of information. To accomplish the paradigm shift, an ontology-supported TFP was developed. The proposed protocol consisted of two parts: ontologies and protocol. To support the design, implementation, and management of transactions in the domain of infrastructure management, two ontologies were developed: the Trans_Dom_Onto and TCA_Onto. Also, the protocol—an eight-step procedure was developed at two levels of abstraction: TFP Specification and TFP Tool. The TFP Specification is a conceptual model that makes a foundation for the TFP Tool. On the other hand, the TFP Tool includes a set of forms and guidance developed for specific steps of the protocol. The TFP Tool was applied in the domain of infrastructure management to develop transaction specifications for the AI&CAR/TCA Reporting, which was implemented in an AIIS. Both the ontologies and protocol were validated through industry experts using criteria based approach. The evaluation results indicate that the transaction development personnel (i.e. transaction analyst, process modellers, software developers, industry experts, and users) can use the protocol effectively and efficiently.     Acknowledgements The authors gratefully acknowledge the Canadian Natural Sciences and Engineering Research Council (NSERC) for their support to this research. References Adesola, S. and Baines, T. 2005. Developing and Evaluating a Methodology for Business Process Improvement. Business Process Management Journal, 11(1): 37-46, Emerald Group Publishing Ltd. Berard, O. and Karlshoej, J. 2012. Information Delivery Manuals to Integrate Building Product Information into Design. Journal of Information Technology in Construction, 17: 64-74. El-Gohary, N. 2008. Semantic Process Modeling and Integration for Collaborative Construction and Infrastructure Development. Ph.D. Thesis, Department of Civil Engineering, University of Toronto. Felio, G. 2012. Canadian Infrastructure Report Card”, Municipal Roads and Water Systems. Vol. 1. Sponsored by Canadian Construction Association, Canadian Society for Civil Engineering, Canadian Public Works Association, and Federation of Canadian Municipalities. Fernández López, M.; Gómez-Pérez, A.; and Juristo N. 1997. METHONTOLOGY: From Ontological Art to Ontological Engineering. Spring Symposium on Ontological Engineering of AAAI, Stanford University, California, USA, pp. 33-40.  Froese, T. 2007. agcXML Generic Document Distribution Use Case. buildingSMART Alliance, National Institute of Building Sciences, USA.  Gómez-Pérez, A. 2001. Evaluation of Ontologies. Intl. Journal of Intelligent Systems, 16: 391–409. Gruber, T.R. 1995. Towards Principles for the Design of Ontologies Used for Knowledge Sharing. International Journal Human-Computer Studies, Academic Press Limited, 43: 907-928. Gruninger, M. and Fox, M.S. 1995. Methodology for the Design and Evaluation of Ontologies. Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal, Canada. Guarino, N. 1998. Some Ontological Principles for Designing Upper Level Lexical Resources. In Proceedings of the 1st International Conference on Lexical Resources and Evaluation. Horridge, M. 2009. A Practical Guide to Building Ontologies Using Protégé 4 and CO-ODE Tools. The University of Manchester, Edition 1.2. 247-9 IAI-IDM. 2012. Building Information Models-Information Delivery Manual, Part 2: Interaction Framework. International Standard, ISO 29481-2, 1st Edition, ISO, pp. 1-74. IAI-MVD. 2005. Model View Definition. International Alliance of Interoperability, buildingSMART International, IFC Solution Factory. Noy, N.F. and McGuinness, D.L. 2001. Ontology Development 101: A Guide to Creating Your First Ontology. Technical Report, KSL-01-05, Knowledge Systems, AI Laboratory, Stanford University, USA. Osman, H.M. 2007. A Knowledge-Enabled System for Routing Urban Utility Infrastructure. Ph.D. Thesis, Department of Civil Engineering, University of Toronto. Protégé. 2014. Welcome to Protégé. National Resource for Biomedical Ontologies and Knowledge, Stanford Center for Biomedical Informatics Research, School of Medicine, Stanford University. PSAB. 2008. Canadian Institute of Chartered Accountants (CICA) Public Sector Accounting Handbook. Canadian Institute of Chartered Accountants, Toronto, Canada. PSAB. 2009. Guide to Accounting and Reporting of Tangible Capital Assets. Public Sector Accounting Board (PSAB), Canadian Institute of Chartered Accountants (CICA), Toronto, Ontario, Canada. Schaap, H.A.; Bouwman, J.W.; and Willems, P.H. 2008. The COINS Systems. Concept Publication, CUR-Report 208-3, CUR Construction and Infrastructure.   SORP. 2008. Draft Statement of Recommended Practices: Assessment of Tangible Capital Assets. Public Sector Accounting Board (PSAB), Toronto, Canada. Stewart, M.A. 2010. Canadian Geospatial Data Infrastructure Information Product 13. GeoConnections Geospatial Returns on Investment Case Study: Multi-Agency Situational Awareness System (MASAS), Developed by New Brunswick Emergency Measures Organization, NRC, Canada. TCA. 2012. School Board and School Authority Tangible Capital Assets. Provincial Accounting Policies and Implementation Guide, Release No. 9. Ministry of Education, Ontario, Canada.  Uschold, M. and Gruninger, M. 1996. Ontologies: Principles, Methods and Applications. Knowledge Engineering Review, AIAI-TR-191, Vol. 11. VISI, 2011. VISI System Guideline Version 1.3. Main Document Normative, Document Version 1, Status Definitive, Developed by CROW. Yu, J.; Thom, J.A.; and Tam, A. 2007. Ontology Evaluation Using Wikipedia Categories for Browsing. Proc. of the 16th ACM Conf. on Information & Knowledge Management, Lisbon, Portugal, pp. 223–232. Zeb, J. and Froese, T. 2011. Design and Management of Transactions in the AEC/FM Industry Using an Ontological Approach. 3rd Intl./9th Construction Specialty Conference, Ottawa, CSCE, pp. 1-10. Zeb, J. and Froese, T. 2012. Transaction Ontology in the Domain of Infrastructure Management. Canadian Journal of Civil Engineering, 39(9): 1-12, Published by NRC Research Press.  Zeb, J. and Froese, T. 2014. An Ontology of Tangible Capital Assets in Infrastructure Management. Infrastructure Asset Management Journal, 1(3): 81-92, Institution of Civil Engineers, UK. Zeb, J. and Froese, T. 2014. Infrastructure Management Transaction Formalism Protocol Specification: A Process Development Model. Construction Innovation: Information, Process, Management Journal, 14(1): 69-87, Emerald Group Publishing Limited.  Zeb, J.; Froese, T.; and Vanier, D. 2012. State-of-the-Art Information Technology Use for Municipal Infrastructure Management. Journal of Information Technology in Construction, 17: 179-193. Zhang, J. and El-Diraby, T. E. 2009. SSWP: A Social Semantic Web Portal for Effective Communication in Construction. Journal of Computers, Academy Publisher, 4(4): 330-337. Zhu, Y. 2007. agcXML Technical Framework (v 0.6). buildingSMART Alliance, National Institute of Building Sciences, USA. Zott, C.; Amit, R.; and Donlevy, J. 2000. Strategies for Value Creation in e-Commerce: Best Practice in Europe. European Management Journal, 5(18): 463-475. 247-10  a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I AJehan ZebThomas Froese (Presenter)5th International/11th Construction Specialty Conference, Vancouver, British ColumbiaJune 08-10, 2015AN ONTOLOGY-SUPPORTEDTRANSACTION FORMALISM PROTOCOLIN INFRASTRUCTURE MANAGEMENTa place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A1 Infrastructure Interdependencies• Better and faster exchange of information between organizations in the public infrastructure sector• Examples:• Coordination during disaster response • “One-Call” centres – checking all underground utilities before excavation• Municipal reporting of infrastructure assets (Public Sector Accounting Board PS 3150 - Tangible Capital Assets)• Part of a larger project on the use of ontologies to support infrastructure interoperability• This project addresses ontologies of infrastructure transactions1. Introductiona place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I AOrganization AShare DataDirect CommunicationUserDocumentUserDocumentData EntryDocumentData EntryDocumentOrganization BDirect CommunicationShare DataData EntryUserUserDocumentDocumentDocumentDocumentData EntryResearch FocusDirect CommunicationSharing DataInter-Organizational FlowDocumentDocument1.1 Introduction1. Introduction4a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A1.2 Overall Approach - Abstraction LayersActor Process / Tool OutputDesignTransaction Formalism ProtocolTransaction Formalism ProtocolSpecificationResearcherDesign Transaction Transaction Specification(message template)TFP ToolAnalystTransaction (message)PerformTransaction Asset Integrator Information Sys.UserSpecifiesResearcherSpecifiesProgrammerTransaction Ontology1. Introductiona place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I ADesign Transaction 1.2 Overall Approach - Abstraction LayersActorDesignTransaction Formalism ProtocolProcess / Tool OutputTransaction Formalism ProtocolSpecificationResearcherTransaction (message)Transaction Specification(message template)PerformTransaction TFP Tool TCA Report SpecificationTCA ReportTCA Reporting SystemAnalystUserTCA OntologyResearcherSpecifiesProgrammerSpecifiesExample: Tangible Capital Asset ReportingTransaction OntologyAsset Integrator Information Sys.1. Introductiona place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A2 Goal and ObjectivesGoal:• Develop an ontology-supported protocol that the transactiondevelopment personnel can use to define transactions for ITimprovement effectively and efficientlyObjectives:• Develop two ontologies:• Transaction Domain Ontology (Trans_Dom_Onto)• and Tangible Capital Asset Ontology (TCA_Onto)• Develop the Transaction Formalism Protocol (TFP)• Develop Asset Information Integrator System for Tangible Capital Asset(TCA) Reporting2. Objectives1. Introductiona place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A4 Point of DepartureA. Relevant OntologiesJoint Infrastructure Interdependencies Research Program (JIIRP) focus includes:• Infrastructure Product Ontology, IPD-Onto (Usman, 2006)• Infrastructure and Construction Process, IC-PRO-Onto (El-Gohary, 2008)• Actor Ontology (Zhang and El-Diraby, 2009)• Transaction Domain Ontology (Trans_Dom_Onto)                (Zeb and Froese, 2011;  Zeb and Froese, 2012: Zeb and Froese, 2015) 4. Points of Departures1. Introduction10a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I ABusiness Domain Ontologies:• Enterprise Ontology (Ushold et al. 1998)• TOVE Ontology (Fox, 1992) • Resource Event Agent, Business Modelling Ontology (Gailly and Poels, 2007) • Open–edi Business Transaction Ontology (ISO, 2006) 4.1 Point of Departure4. Points of Departures1. Introduction11a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A• BuildingSmart (IFC) Process Standards:• Information Delivery Manual – IDM, (IAI-IDM, 2007 and IDM, 2012)• Formalizes data exchange processes using IFC data.• Model View Definition – MVD, (IAI-MVD, 2005)• Formalizes IFC views (model sub-sets) to support specific data exchange situations.4.2 Point of Departure4. Points of Departures1. Introduction12a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A• Dutch Construction Industry Standards:• Voorwaarden Scheppen Voor Invoering Standaardisatie, (VISI, 2007 and VISI 2011) • Agreements on generic process maps and exchange requirements.4.3 Point of Departure4. Points of Departures1. Introductiona place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A• ebXML (ISO, 2005)• Enable enterprises of any size located in any geographical regionto conduct business over the internet.• RosettaNet (RosettaNet, 2012 and Damodaran, 2004)• Develop and implement Partner Interface Processes (PIPs) toenable electronic business in the supply-chain industry. The PIPsare standardized processes that allow trading partner to developpartnerships quickly and conduct business in a consistent way.4.4 Point of Departure4. Points of Departures1. Introduction14a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I ATransaction Domain Kernel Ontology                                                                                  Core ConceptsTransactionInformationActor_Role ActorMessagerepresentedIntransmittedIncontrolMessage_Instance instantiateHeader_InformationPayload_InformationOrganization_ActorIndividual_ActorStakeholder_RoleTransaction_RolereflectedInnameReflectedInparticipateInplaySupport  ConceptsModalityMechanism enable classifyTransaction_Communication_ChannelRelationshipConstraintconstrainenrichAxiomAttribute5. Build Ontologies—Transaction Domain Ontology 5. Onto. Dev. & Evaluation1. Introduction16a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A5.1  Tangible Capital Asset OntologyTangible_Capital_Asset_ModalityFunction_Asset_ModalityComposition_Asset_ModalityIndividual_Asset_ModalityTangible_Capital_Asset classifyInfrastructure_Sector_ModalityFacility_Sector_ModalitySector_Asset_Modality5. Onto. Dev. & Evaluation1. Introduction17a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I AA B C4.75 4.67 4.25 4.604.83 4.83 4.67 4.804.57 4.71 4.36 4.502 Disagree5 Strongly Agree0 Unable to Rate 1 Strongly Disagree3 Neither Agree nor Disagree 4 AgreeClarityCompletenessCorrectnessAverage ScoreAverage Agreement RatingTransaction Domain Ontology ValidationCriteriaRespondentsA B C4.88 4.75 4.83 4.84.82 4.76 4.73 4.84.74 4.7 4.41 4.6CompletenessCorrectnessTangible Capital Asset Ontology ValidationCriteriaRespondentsAverage ScoreAverage Agreement RatingClarity5.2 Ontology Validation—Results of Expert Review 5. Onto. Dev. & Evaluation1. Introduction18a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A6 Transaction Formalism Protocol Development  Assess   NeedsDefine        As-is TMDevelop To-be TMCollect InformationReview     TM/MTMonitor   STAGuidanceFormsTFP ToolImplement TM/MTDesign MT 6. TFP Dev. & Evaluation1. Introduction19a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A6.1 Transaction Formalism Protocol Specification A1Assess                                NeedA2Define                    As-is TMA3Develop                                      To-be TMA4Collect  InformationA5Design                    MTA6Review                    TM/MTA7Adopt and ImplementA8Monitor               STAC1Organisational PolicyC2Assessment CriteriaC3LocationC4Contractual Requirements I1 Transaction SetI3 Expert InterviewI2 Use CasesTransaction ListI4 Transaction System Design C5 ExpertiseC6User Exchange Requirements C7 Use Design RequirementsC8 Regulatory RequirementsC9 Security  RequirementsAs-is Transaction PerformanceAs-is TMPerformance Report Specifying ImprovementsM1 Transaction Development Personnel (Transaction Analysts, Transaction Designers, Software Developers, Process Modellers, and Industry ExpertSoftware DeveloperIndustry ExpertSoftware DeveloperFinal TM requires RevisionFinal MT requires RevisionPurpose and ScopeTo-be Transaction PerformanceTo-be TMTo-be TMPayload InformationHeader Infor.Message TemplateO1 Final MT O2 Final TMO3Transaction SystemO4 Performance ReportA0Transaction Formalism ProtocolMechanismControlInput OutputTM – Transaction MapAbbreviations:MT – Message TemplateSTA – Standard Transaction AgreementA61Produce       STAA71Adopt by PartiesA72Implement in SoftwareStandard Transaction AgreementTransaction Development PersonnelFinal Message TemplateFinal Transaction MapTransaction SystemStandard Transaction AgreementC6 C8C7C4C6C4C4 C8C6C36. TFP Dev. & Evaluation1. Introduction20a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A6.2 Transaction Formalism Protocol Tool NameE-mail AddressDate ConductedSingle or List of TransactionManual/    Paper-basedCriticalCostlyFrequentLiklihood                   of Mgt.ComplexContractual Req.Regulatory Req.Total Scorei. Tangible capital asset reporting (PSAB-3150) √ √ √ √ 4ii. Asset inventory & condition assesssment reporting √ √ √ √ 4iii. Pavement condition assessment reporting √ √ √ √ 4iv. Request for proposal √ √ √ √ 4v. Submission of project as-built information √ √ √ √ 4vi. Request for services √ √ √ √ 4Assessment Criteria - (tick all that applies) Experts in the domain of infrastructure management identified a list of transactions that have the greatest potential for IT improvement. All the identified transactions obtained same scores; however, it is decided to formalize tangible capital asset reporting transaction first, due to urgent compliance with the Public Sector Accounting Board reporting requirement. Moreover, other transactions on the list will be formalized later.Technical InformationAssess Needs - Step 1General Administrative InformationXYZxyz@hotmail.com30/05/12  (dd/mm/yy)Description of Transaction Selection6. TFP Dev. & Evaluation1. Introduction21a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I AA B C D E5.0 4.3 4.7 4.7 4.3 4.65.0 4.0 4.3 5.0 4.7 4.64.4 4 4.8 4.8 4 4.44.0 5.0 5.0 4.0 4.0 4.4Feasibility 0 Unable to Rate                         1 Strongly Disagree                  2 Disagree                                            3 Neither Agree nor Disagree                           4 Agree                                       5 Strongly AgreeUseability Generalizeability UsefulnessTransaction Formalism Protocol ValidationCriteriaRespondentsAverage Score LegendsAverage Agreement Rating6.3  Transaction Formalism Protocol Validation—Results of Expert Review 6. TFP Dev. & Evaluation1. Introduction22a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A7. Asset Inventory and Condition Assessment Reporting – (As-is)             Implemented in AIIS1. Prone to errors due to human interpretation2. Time consuming to extract and compile data manually3. Difficulty in interpreting different TCA reports Municipal GovernmentInfrastructure Management SystemsCityTownDistrictVillageProvincial GovernmentInfrastructure Management SystemsTCA 1TCA 2TCA 3TCA 4Heterogeneous Tangible Capital Asset Data TCA 4TCA 3TCA 2TCA 1 E-mail  File Attachment7. Asset Info. Integ. System1. Introduction23a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I AMunicipal GovernmentCityTownDistrictVillageInfrastructure Management SystemsProvincial GovernmentProvincial GovernmentAsset Integrator Information System (AIIS)7.1 Asset Inventory and Condition Reporting – (To-be), Implemented in AIISDefine To-be TMs and MTs—Transaction SpecificationsTCA TCATCATCATCATCA Template based Exchange TCA TCA TCA Improvements:• Process Improvement• Information Improvement• Mode ImprovementAsset Informatio  Integrator Syste  ( IIS)Project_Services_Delivery_Sector_ TransactionCollabor tion_ TransactionDomain_  TransactionControl_ TransactionBusiness_ TransactionChannel_TransactionInterf e_ TransactionActor_Role_ Centered_Pattern_TransactionCommunication_TransactionTemplateActor_RoleActor_RoleTransaction AgreementsTransaction_PortalPortal_Architecture7. Asset Info. Integ. System1. Introduction24a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I A7.2 Asset Information Integrator System  7. Asset Info. Integ. System1. Introduction25a place of mindT H E  U N I V E R S I T Y  O F  B R I T I S H  C O L U M B I ATHANKS

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.52660.1-0076344/manifest

Comment

Related Items