DEVELOPMENT OF A MODEL FOR DATA EXCHANGE OF EXPERIMENTAL RESULTS

DEVELOPMENT OF A MODEL FOR DATA EXCHANGE OF EXPERIMENTAL RESULTS Gustavo Sudre1, William V. Kritikos1, Adolfo Matamoros2, Sharon L Wood3

ABSTRACT Data exchange in the earthquake engineering field is carried out primarily through research reports, or through computer files in a multitude of different and often proprietary digital formats. This state of practice increases the cost of sharing the data, and leads to the loss of important information over time. Ontologies containing formal descriptions of domain specific terms and the relations among them can be used to create machine-understandable metadata to facilitate the exchange of data among different systems and users. This paper discusses the development of an ontology to describe relations among researchers and data from a project evaluating soil-structure-foundation interaction in a reinforced concrete bridge structure. The ontology, created using the Web Ontology Language, integrated newly and previously developed data models and ontologies such as the Industry Foundation Classes and the Dublin Core to describe the experimental configuration, the properties and geometry of the specimen, the testing protocol, the experimental results, and the people involved in the research project. The procedure used in developing the ontology is described, and recommendations for the future development of ontologies describing the earthquake engineering domain are presented. Introduction The need for complex physical simulations in the earthquake engineering has lead to an increasing number of collaborative research programs in which participants from various institutions make shared use of geographically distributed experimental facilities. This type of organization requires that increasingly larger pools of information be made accessible and easily understandable to large groups of researchers, making effective archival and management of data a key factor for successful collaboration. The amount of information generated and managed will continue to grow at an increasing rate with advances in sensor and computer technology. In the current state of practice computer files in a multitude of different and often proprietary digital formats are the preferred media to store this information. This state of practice increases the cost of sharing the data, and leads to 1

Research Assistant, CEAE Department, University Of Kansas, Lawrence, KS 66045 Associate Professor, CEAE Department, University Of Kansas, Lawrence, KS 66045 3 Professor, Dept. of Civil, Architectural, and Environmental Engineering, University of Texas, Austin, TX, 79712 2

the loss of important information over time. Therefore, new ways to manage and retrieve these data are needed in order to provide users with better tools to perform tasks such as searches, comparisons, and automated reasoning. The use of ontologies and descriptive metadata has proven to be an effective solution to such problems (Cihon, 2003) (Sujanani, 2005) (Corcho, 2005) (Razdow, 2005) (Pinto, 2003). These two concepts and how they relate to one another are explained in the following. An ontology is a formal and explicit description of concepts in a certain domain. It features properties and their restrictions for each concept, as well as relationships among the concepts. A concept can be any physical object or abstract idea which bears a definition in a domain area. For example, if we analyze the bridge domain, we can identify the structural components of a bridge (i.e. girder, pier, abutment, etc.) as concepts. Two of the most important properties of an ontology are its scope and granularity. The scope of an ontology defines the regions of a domain that will be referenced in the ontology, such as structural components, materials, and function. Granularity refers to the level of detail used to describe the information of a domain. For the bridge domain example, the number of structural components (concepts) that constitute the ontology is dependent on these two properties. A useful quality of ontologies is their ability to separate domain knowledge from operational knowledge, which means that the same theoretical knowledge described in an ontology can be used in multiple practical areas. For example, if one has an ontology about the basic components of a bridge, it can be used for bridge management or bridge design. This is extremely valuable when attempting to reuse and extend existing ontologies. With the help of a reasoner, logical conclusions can be derived from a well-constructed ontology, in a process called automated reasoning. There are multiple ways to use ontologies in the field of information technology (Noy, 2001). Because all the agents (e.g. software, people) that use the information need to speak the same vocabulary to achieve better connectivity, knowledge sharing can be seen as the first area where ontologies can be used. Also ontologies are useful to avoid the process of “re-inventing the wheel”, which is inefficient and time consuming, and facilitate the reuse of domain knowledge to increase productivity. This can be done for example by integrating several existing ontologies to describe portions of a larger domain. Metadata means data about data. In other words, metadata is any kind of information that can be used to identify or describe a concept. For example, one can think about the information in an old library card as metadata about a book. Similarly, metadata about a text document might include information about the contents, the author, file size, and the program used to write the document. While an ontology maps the relationships between the concepts within a domain, having metadata is essential for archiving and retrieving data. The combination of having a welldeveloped ontology to describe a domain and metadata about the data improves the chances of finding specific information within a large collection of data, provides the capability of using reasoning to derive conclusions about the data, and decreases the cost and time that must be invested in finding it. Compared with the standard keyword-based search performed by many of the current search engines, a context-based search using the domain described by an ontology presents greater capabilities. For example, if an engineer is looking for the parts of the superstructure of a bridge that have been inspected on a given date, a keyword-based search will only reference certain documents if they contain the word superstructure in them. Because an ontology would

describe concepts such as deck and girder as components of the superstructure, all documents that contain such concepts would also be included in the search. In this way, a context-based search paired with an ontology has potential to maximize the relevant results of a search, which ultimately increases productivity. Ontology Engineering Ontology engineering is still a relatively new field compared with other engineering areas, such as structural engineering, or even other areas of computer science such as software engineering. For this reason, there is no standard method or guideline to build an ontology, which means that there is not an agreed-upon best method to do it. The approach adopted for this project was derived from various methodologies documented in the literature (Gómez-Pérez, 1999; López, 1999), and consisted essentially of seven steps. It is important to notice that these steps were not carried out in chronological order, and that they frequently occurred concurrently. During the specification phase, the developers identify the crucial parameters which will guide the rest of the ontology development process, such as why the ontology is being built, what are its intended uses, and a set of terms that need to be present in the ontology. It is during this stage that the scope and granularity of the ontology are defined. During the knowledge acquisition step, the developers research the domain in order to have clear perspective of what are the most important concepts and how they relate to each other. Other people that contribute during this step are the subject matter experts (SMEs), because they can be consulted by the developers regarding questions about the domain. Still in this step, a list of competency questions (questions the ontology should be able to answer when finished) is formulated. The next step is integration, which involves searching for other ontologies that were already developed and which cover smaller parts of the ontology being developed. Good examples of ontologies which can be reused are ontologies that describe time, geometric figures, document attributes (e.g. Dublin Core (DCMI, 2005)), and units. During the conceptualization stage, developers start to formally define classes, properties, and restrictions based on the domain knowledge acquired. There are usually three common approaches of describing a domain (Semy, 2004): starting with the definition of the most general concepts in the domain and subsequent specialization of the concepts (top-down); starting with the definition of the most specific classes with subsequent grouping of these concepts into more general concepts (bottom-up); and defining the most important concepts first, and then generalizing and specializing these appropriately (middle-out). The documentation of an ontology should be done while the elements of the ontology are still described in an abstract and strictly conceptual form, independent of any kind of implementation. Following the documentation stage, any person should be able to code the design in any language he or she desires. By referring to the documentation, the developers build a computable model representing the ontology using a specific a computational language. The Protégé graphic interface (Protégé, 2005) and Web Ontology Language (OWL) (OWL, 2004) were chosen in this project for the implementation stage because they provided powerful features and high integration of the language with the Semantic Web (Berners-Lee, 2001), and because of the robustness of the design environment of the graphic interface. Finally, maintenance is an on-going phase for every ontology. The ontology should frequently be checked for accuracy, particularly if the concepts described in the ontology are

likely to change with time. SFSI Project Ontology An ontology was developed at the University of Kansas with the target domain of earthquake engineering research. The definition of the domain was based on the research project that the ontology was intended to support. The research project investigated soil-foundationstructure interaction in a reinforced concrete bridge supported on drilled shaft foundations (Wood et al., 2004), and it involved tests in several different NEES facilities. An ontology was developed as part of the IT component of the project to investigate alternatives for organizing and archiving data and metadata generated in such a large project. A second objective was to explore the advantages and disadvantages between the different methods for developing ontologies when applied to the earthquake engineering domain. The broad scope of the research created an interesting problem; the research was carried out at multiple universities, each of which conducted very different types of physical and computational simulations. Field testing of ¼-scale specimens of the bridge bents and foundations were carried out at the University of Texas with mobile shakers, physical simulations of small-scale specimens of the bridge and its foundation where carried out in a geotechnical centrifuge at University of California, Davis, a ¼-scale model of the bridge with rigid foundations was tested on the earthquake simulator at the University of Nevada, Reno, pseudo static tests of ¼ and ½-scale columns and bridge piers are being carried out at Purdue University, and computational simulations were carried out at multiple universities. In order to make an ontology that could sufficiently cover all of the research areas in the SFSI project, the scope of the ontology had to be general enough to encompass the most important concepts needed to define an engineering research project. Also, the ontology had to be extensible in order to allow experts to express the fine details particular to each class of experiment. Ontology Design Goals and Scope Two main goals were established during the specification phase of the SFSI project ontology. The first goal was to represent information about an earthquake engineering research project in a format that explicitly contained information about projects in general, while allowing for extensions applicable to each specific type of experiment. The second goal was to have a high level of interoperability. This meant that whenever possible, the ontology was built from existing standard ontologies. This method allowed storing information from the SFSI project in an format similar to other widely-adopted ontologies, facilitating interoperability with already existing software. The scope of the SFSI Project Ontology was defined to cover the following concepts:  Research project information  People and organizations involved, including contact information and roles in the project  Scientific units of measurements  Time and date of events  Experiment information  Specimen construction specifications  Loading protocols

   

Geometric representation of specimens Material properties Information about of sensors and actuators, including calibration data and placement Boundary conditions

Interoperability of the SFSI Ontology with the Industry Foundation Classes As previously stated, one of the goals of the SFSI Ontology was to achieve a high level of interoperability with existing software and widely-adopted data models. For this reason the Industry Foundation Classes (IFCs) (IAI, 2004a) were merged into the SFSI Ontology to describe concepts related to specimens, materials, and the project in general. The use of the IFCs presented both advantages and limitations. Because the IFCs were developed for describing large construction projects, concepts related to a research project had to be added through extensions. During the integration phase the most important concepts in the research domain were matched with similar concepts in the IFCs. The description of the concept adopted in the IFCs was usually extended to add important information specific to the research domain. An example of this process applied to the concept of a research project is described in the following. The definition of a project in the IFCs is intended to describe a construction project (IAI, 2004b). It includes the complete name of the project, the current phase of the project, and the unit system used in the project. In the SFSI Ontology that definition was extended by adding descriptions of the experiments that make up a research project, the roles of people and organizations involved in the project, and the results created during the project. This process of extending existing concepts was used extensively during the conceptualization phase of the SFSI Ontology. For example, an experiment was defined as an extension of the IfcProcess (IAI, 2004b) class. Specimens were defined as extensions of the IfcProduct (IAI, 2004b) class. It is important to note that it was not necessary to extend all the IFCs concepts used in the research domain. For example, the IFCs description of scientific units (IAI, 2004b) and time (IAI, 2004b) had higher granularity and larger scope than what was needed for the research domain. By extending the IFCs concepts only when needed, the amount of data stored in the IFCs format was maximized, which was important for maximizing the interoperability of the ontology. Description of SFSI Project Ontology Conceptually, the highest class in the SFSI Ontology is the Research Project class. A research project has properties which list the experiments carried out as part of the project, the project-level results, the roles fulfilled by people and organizations participating in the project, and other details. The Experiment class contains the most information of any single class. The properties of the Experiment class are the starting time and date, ending time and date, experimental procedure, experimental results, setup information, role information, and the subexperiment information. Any experiment can have any number of sub-experiments. A subexperiment has all of the properties of a normal experiment, including the ability to have subexperiments itself. Some uses of a sub-experiment include doing multiple trials or runs while using the same experimental configuration, or conducting a calibration experiment to test the functionality of the sensors. This concept is illustrated in Figure 1. Two subclasses of

experiments were created: computational experiment and physical experiment. The computational experiment subclass was created to describe computer simulations, and its properties were created to describe the computational model used in the simulation. The physical experiment subclass was created to describe physical simulations, and its properties are used to describe specimens and testing equipment used. For greater flexibility, the class specimen can be Experiment 1 Experiment 2 Experiment 3 ...... Experiment N represented using an instance of the IfcProduct class, ...... Trial 1.1 Trial 1.2 Trial 1.N Trial 3.1 which contains the geometric and material properties of ...... Trial 1.1.N Trial 1.1.1 the specimen, or in lieu of that, using Trial 1.1.1.2 ...... Trial 1.1.1.N Trial 1.1.1.1 external documents such as AutoCAD (Autodesk, 2005a) Figure 1: SFSI Ontology Project Level Hierarchy drawings and text files detailing the properties of the materials used in the specimen. An instance of the IfcProduct class is the preferred method, because of its potential for classifying and retrieving information through search engines, and because of its advantages in terms of interoperability. The option to attach a less formal description, such as through the use of drawing files, was included to reflect the current state-of-the-art of information sharing in the earthquake engineering field. Creating an instance of the IfcProduct class to describe a specimen is not a task that can be easily done manually. The process that was used in this project started by generating a three-dimensional model of the specimen using AutoCAD. An example of a three-dimensional model is shown in Figure 2. This is a representation of a bridge specimen tested at the University of Nevada at Reno. The materials and material properties were specified using Autodesk Architectural Desktop (Autodesk, 2005b). Finally, the specimen representation was exported into the IFCs format using a conversion utility called IFC Utility 2x (Inopso, 2005). The IFCs data model was developed using a language called EXPRESS (IAI, 2005), which is different from the OWL language (OWL, 2004) used in the development of the SFSI Project Ontology. A utility called ifc2owl, developed at the University of Kansas, was used to convert the specimen representation from EXPRESS to OWL. After this conversion, the specimen could be referenced as an instance of the IfcProduct class by the physical experiment subclass. All physical objects, except for people, are considered resources within the IFCs, including the representation of the specimens, sensors, and loading equipment. These resources may be physically attached to one-another, may have to be calibrated or set to certain values, or constructed. All of these activities are captured in the super-class Resource Setup, which is a subclass of IfcProcess. The subclasses of the Resource Setup class are setting, construction procedure, calibration, boundary condition, and attachment. Each of these subclasses include properties listing the resources that are affected, and a reference to external documents that may Project A

be used to describe the setup. One of the most important concepts in the SFSI Ontology is constituted by the results from the research project, which include experiment results, project reports, and sensor data. These are represented using the class Result. An instance of the class Result can be created at all levels of the project tree, meaning that projects, experiments, and all sub-experiments can generate results. If a particular sub-experiment was a single trial in a larger experiment, the result from that sub-experiment may be the raw sensor data. The result from the corresponding experiment may include some initial analysis done by combining and processing sensor data from the multiple trials. The project level results would include reports and articles describing the entire project. The actual sensor data is not contained in any class of the ontology, primarily because of the wide range of data formats used in the different testing facilities. Instead, references to external Figure 2: Example 3D representation of bridge specimen documents that contain the actual data are provided, along with Dublin Core (DCMI, 2005a) annotations for each document. This architecture allows any type or size of document to be included in the SFSI Ontology. The Dublin Core Metadata Initiative (DCMI) produced a standardized set of metadata about documents which can help businesses and researchers organize the documents in their collections. The most common metadata associated with documents are the author, title, and subject. The Dublin Core includes these metadata elements, as well as many more. A complete list of metadata terms included in the DCMI can be found at its website (DCMI, 2005b). The Dublin Core was adopted because it is a widely accepted standard (DCMI, 2005c) for managing documents. There are multiple documented cases of projects focusing on document management that have adopted subsets of the Dublin Core as a standard sets of metadata to include for each file. This presents advantages in terms of interoperability with tools designed to manage information and to generate metadata created in accordance with the Dublin Core. Figure 3 details how different sub-domains are covered in the SFSI Ontology. The concepts listed in the central oval are covered by the IFCs. The lower oval specifies that the Dublin Core was used to extend the sub-domain of external documents within the IFCs. The upper oval shows that the research project and experiment concepts were covered using new classes developed for the SFSI Ontology.

Optimal Large-Scale Ontology Integration In the process of the developing the SFSI Ontology, there were several characteristics

observed to be important for developing ontologies within the engineering domain. Modularity is one of the most important characteristics. The advantages of combining smaller ontologies that describe sub-domains into a larger ontology were evident. If small ontologies are developed by experts in their own fields to describe in a very detailed manner specific sub-domains, other developers building ontologies in related fields could reuse that knowledge leading to faster development and improved interoperability. For example, an ontology that describes the properties and the relationship between the properties of concrete, could be used by developers creating ontologies to describe building structures, bridges, roadways, houses, dams, off-shore platforms, etc. By developing small ontologies describing domains such as scientific units, time, materials, geometry, physics, standard shapes, colors, etc., ontologies describing larger domains could easily be developed by focusing on the most important concepts of the larger domain and the integration of the relevant sub-domains, rather than having to describe each of the subdomains to great detail. There are several Research SFSI Ontology Experiments Projects problems which must be resolved in the process of creating an optimal system. The first problem is reaching consensus in the development of ontologies IFCs for the sub-domains. This People & problem implies the need SI Units Projects Documents Specimens Organizations for a governing body to facilitate consensus among experts and the Dublin Core Document development of standards Information to describe the information in each sub-domain. The second problem is one of Figure 3: SFSI Ontology Sub-Domain Integration completeness. The subdomain ontologies must have a high degree of granularity, because they may be used by higherlevel ontologies with different requirements. Another problem with modular design is that all sub-domain ontologies have to follow some general formatting rules, in order to facilitate their interoperability. This aspect is key for the integration of sub-domain ontologies into higher-level ontologies. Again, a governing body must be in charge of reaching consensus on the best format to use. One common formatting issue is capitalization and punctuation of class names. For example, a class could be named “Research_Project”, “ResearchProject”, “research_project”, or “research-project”. Most current ontology development environments, such as Protégé, are case sensitive. All of these names would appear as separate classes in Protégé, even though to a human, it is obvious that they are all the same. Approaching ontology development in this manner would alleviate many problems encountered today in the field of information technology, and would result in better interoperability. Individuals managing information within the same domain could rely on the same ontology and software to manage information. This would make the exchange of information more efficient and economical, would make it feasible to develop better software

tools because of the larger user base, and would make it easier to store and retrieve information in a manner that is understandable to a larger group of users. Individuals working in related domains would be able to leverage the ontologies and software as well to describe more complex concepts. Conclusions This paper lists steps and recommendations for developing ontologies in the earthquake engineering domain. Even though storing standardized metadata is not a well established practice within the earthquake engineering field, it is crucial to develop and implement policies to guarantee the creation of metadata for new information obtained through research projects. Additionally, such policies must establish minimum standards for required and optional metadata. The implementation of the SFSI ontology showed that the use of widely accepted ontologies leads to improved interoperability among different agents. By relying on the IFCs and DCMI it became possible to use widely-available software to generate data and metadata about the experiments. Although this project managed to implement an ontology using the IFCs, there were still limitations originated by the choice of using this model. The first restriction was related to the conversion process between ontology implementations. Because the IFCs implementation was originally coded in Express, and the tool used to convert it to OWL did not convert every single relationship between concepts and properties. Secondly, the IFCs have a very concise structure, instead of the modular structure recommended in this paper. For that reason, it was necessary to rely on the complete set of IFCs, instead of reusing only the parts that were essential to the SFSI ontology. This structure also made the process of extending the IFCs classes more complicated. Finally, there is a great need for the development of tools to facilitate the extraction and creation of metadata. This problem can be greatly reduced by relying on standardized ontologies, as described in this paper. Even if created without any prevalent standards, having some form of metadata is better than having no metadata at all. However, standardized methods to generate and organize metadata are important to facilitate the development of better software agents to manage information, and to make the information useful to a larger number of users. Acknowledgments This work was supported in part by the National Science Foundation under Award CMS 324326 to the University of Texas at Austin through a subaward to the University of Kansas. The opinions expressed in this paper are those of the researchers, and do not necessarily reflect those of the sponsor. The authors would like to acknowledge contributions from other members of the SFSI research group, in particular those of Prof. David Sanders from the University of Nevada and Julio Ramirez from Purdue University who provided valuable feedback for the paper. References Autodesk, 2005 A. AutoCAD Product Information [online]. Available from World Wide Web: (http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=2704278). Autodesk, 2005 B. Autodesk Architectural Desktop Product Information [online]. Available from World Wide Web: (http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=2956700). Berners-Lee, T., Hendler, J., Lassila, O., 2001. The Semantic Web. Scientific American. May 2001.

Cihon, R., 2003. Why Data? The Need to Consider Other Issues for GIS-T. [online] Washington State DOT. Available from World Wide Web: (http://www.gist.org/yr2003/gist2003sessions/Session412.ppt) Corcho O, Fernández-López M, Gómez-Pérez A, López-Cima A., 2005. Building legal ontologies with METHONTOLOGY and WebODE. Law and the Semantic Web. Legal Ontologies, Methodologies, Legal Information Retrieval, and Applications. March 2005. Springer-Verlag, LNAI 3369. DCMI, 2005a. Dublin Core Metadata Initiative [online]. Available from World Wide Web: (http://dublincore.org/). DCMI, 2005b. DCMI Metadata Terms [online]. Available from World Wide Web: (http://www.dublincore.org/documents/dcmi-terms/). DCMI, 2005c. Dublin Core Projects – Alphabetical [online]. Available from World Wide Web: (http://www.dublincore.org/projects/). Gómez-Pérez, A., López, M. F., Sierra, J. P., and Sierra, A. P., 1999. Building a Chemical Ontology Using Methontology and the Ontology Design Environment. IEEE Intelligent Systems 14, 1 (Jan. 1999), 37-46. IAI, 2004a. IFC/ifcXML Specifications [online]. Available from the World Wide Web: (http://www.iaiinternational.org/Model/IFC(ifcXML)Specs.html). IAI, 2004b. IFC2x2 Addendum 1 IfcProject Definition [online]. Available from the World Wide Web: (http://www.iai-international.org/Model/R2x2_add1/ifckernel/lexical). IAI, 2005. The EXPRESS Definition Language for IFC Development [online]. Available from World Wide Web: (http://www.iai-international.org/Model/documentation/ The_EXPRESS_Definition_Language_for_IFC_Development.pdf). Inopso, 2005. IFC-Utility 2x for ADT [online]. Available from World Wide Web: (http://www.interoperable.de/inopsoweb/ifcsolutions_en.htm). López, M., 1999. Overview of Methodologies for Building Ontologies. IJCAI99 Workshop on Ontologies and Problem-Solving Methods: Lessons Learned and Future Trends, Stockholm, 1999. Noy, N., McGuiness, D., 2001. Ontology Development 101: A guide to creating your first ontology. KSL Technical Report. Standford University, 2001. OWL, 2004. OWL Web Ontology Language: Overview [online]. Available from World Wide Web: (http://www.w3.org/TR/owl-features/). Pinto, H. S. and Peralta, D. N., 2003. Combining ontology engineering subprocesses to build a time ontology. In Proceedings of the international Conference on Knowledge Capture (Sanibel Island, FL, USA, October 23 - 25, 2003). K-CAP '03. ACM Press, New York, NY, 88-95. Protégé, 2005. Protégé Ontology Editor and Knowledge Acquisition System [online]. Available from World Wide Web: (http://protege.stanford.edu/). Razdow, A., 2005. Extending the Power of XML to the Engineering Enterprise: How XML Will Improve Product Development, Quality, Compliance and Integration [online]. Available from World Wide Web: (http://www.mathsoft.com/solutions/papers/2528.asp) Semy, S. K., Hetherington-Young, K. N., Frey S. E., 2004. Ontology Engineering: An Application Perspective [online]. Available from World Wide Web: (http://www.mitre.org/work/tech_papers/tech_papers_04/04_0847/04_0847.pdf) Sujanani, A., Ray, P., Paramesh, N., and Bhar, R., 2005. The development of ontology driven multi-agent systems: a case study in the financial services domain. In Proceedings of the IEEE Eee05 international Workshop on Business Services Networks (Hong Kong, March 29 - 29, 2005). ACM International Conference Proceeding Series, vol. 87. IEEE Press, Piscataway, NJ, 1-1. Wood, S., Anagnos, T., Arduino, P., Eberhard, M., Fenves, G., Finholt, T., Futrelle, J., Jeremic, B., Kramer, S., Kutter, B., Matamoros, A., McMullin, K., Ramirez, J., Rathje, E., Saiidi, M., Sanders, D., Stokoe, K., Wilson, D. 2004. Using NEES to Investigate Soil-Foundation-Structure Interaction. 13th World Conference on Earthquake Engineering, Vancouver, B.C.