UNIVERSITY OF MARYLAND COLLEGE PARK SYSTEMS ENGINEERING VALIDATION AND VERIFICATION ENPM643 TERM PROJECT: Ontology-Enabled Validation of Systems containing Electric Terminals FINAL REPORT PROFESSOR: MARK AUSTIN STUDENT: FRANCISCO J GALLO DEC/6/2005UNIVERSITY OF MARYLAND – COLLEGE PARK ENPM643 – Term Project – Document: FinalReport_v.0.1.doc Author: Francisco Gallo 1/10 TABLE OF CONTENTS 1. DESCRIPTION OF PROJECT ..................................................................... 2 2. INTRODUCTORY REMARKS...................................................................... 2 3. FINAL DELIVERABLES OBTAINED FROM THIS PROJECT .......................... 2 4. PROJECT IMPLEMENTATION DESCRIPTION ............................................ 3 4.1. STEP: ANALYSIS OF BASE SYTEM AND CREATION OF BASIC RULES FOR ONTOLOGY................................................................................................. 3 4.2. STEP: IMPLEMENTATION OF ONTOLOGY IN PROTÉGÉ................................ 3 4.3. STEP: GENERATION OF XML FILES AND CREATION OF XSLT STYLE SHEETS .. 4 4.4. STEP: CREATION OF ONTOLOGY VALIDATION TOOL ................................. 5 5. STEPS FOR USING THE ONTOLOGY VALIDATION TOOL........................... 8 6. REFERENCES ......................................................................................... 10UNIVERSITY OF MARYLAND – COLLEGE PARK ENPM643 – Term Project – Document: FinalReport_v.0.1.doc Author: Francisco Gallo 2/10 1. DESCRIPTION OF PROJECT The primary goal of this project is to develop a tool that allows the validation of connections between electrical terminals. Secondary goals of this project are: 1) Define a framework for defining and identifying the different elements needed to interconnect components in a system. This framework is approached at a case study level and can be extended as necessary. 2) Using the framework, create an ontology that implements key aspects of it and that allows to validate the use of components included in the ontology. 3) Implement a tool that is capable of validate connectivity of electrical terminals by using the hierarchical schema defined in the ontology. 4) Use XML as a data-storage mechanism to validate formal data and to move it between applications. 5) Gain understanding of tool Protégé. 2. INTRODUCTORY REMARKS Work done in this project was based on papers by [Mayank] and [Liang] and on reference materials provided by Professor Mark Austin. This project was strongly based on the following technologies: 1. Stanford’s Protégé 2. XML 3. XSLT 4. XPATH 5. VBA 6. Excel 3. FINAL DELIVERABLES OBTAINED FROM THIS PROJECT 1. Ontology Validation Tool: Implemented in VBA and Excel XP. This tool is capable of importing XML data containing instances of a predefined ontology and then, allows the user to test connectivity between elements. This tool displays detailed information about compatible/incompatible attributes and works seamlessly with XML generate by Protégé. The ontology validation tool has been implemented as a macro in file “OntologyValidationTool_V.N.n.xls”. 2. Ontology in Protégé: A Protégé project containing an ontology for electrical ports has been fully implemented. This ontology is based on the rules and knowledge gained by analyzing a Home Theater System. The Protégé project has been include in file “PortOntology.pprj”. 3. Electrical Terminal Ontology Specification: Document (see file “Annex01_ElectricTerminalsOntologySpecification”)) containing the analysis process done on a Home Theater System. This analysis provided the framework to implement the ontology in Protégé. Other achievements done as result of this project: 1. Analyzed the XML hierarchy that Protégé creates. Documented this hierarchy in file “Annex04_ProtegeXMLSchemaAnalysis.xls” for future reference.UNIVERSITY OF MARYLAND – COLLEGE PARK ENPM643 – Term Project – Document: FinalReport_v.0.1.doc Author: Francisco Gallo 3/10 2. Created XSLT template using XPATH to provide style to XML generated by Protégé allowing seamless integration with XML/XSLT capable environments. 4. PROJECT IMPLEMENTATION DESCRIPTION 4.1. STEP: ANALYSIS OF BASE SYTEM AND CREATION OF BASIC RULES FOR ONTOLOGY Due to the complexity of this step, it was decided to include it as an Annex. Please refer to file “Annex01_ElectricTerminalsOntologySpecification_v.0.2.doc” for details on how this was done. Please note that some Annex 1 provides some important definitions that will be used from now on. It is strongly recommended to read it before continuing with present document. 4.2. STEP: IMPLEMENTATION OF ONTOLOGY IN PROTÉGÉ Through an iterative process using Protégé, the ontology needed to describe a set of electrical terminals was implemented. This ontology is in a Protégé project file. The Electrical Terminals Ontology (ETO) implemented in Protégé is focused in the description of the Terminals needed for a set of ports to work properly. Bear in mind that a Port is a composition of Terminals. Concepts used to categorize the classes and defining their attributes are based on Liang [2]. These are: function, behavior and form. Function has been used to define the top-level classes based on the nature of the service they provide. For example: power or information transmission. Behavior has been used to define the bottom-level classes based on how the service is implemented. For example, digital or analog signals. Also, behavior has been used to define certain attributes of the classes, such as the operating frequency, impedance and others. Form has been provided as an attribute in the ontology. Since describing the form of a connector implies a complexity beyond the scope of this project, the abstract approach to shape specifications suggested by Liang [3] is used. This is, instead of providing the physical details of form, a certain standard name is defined (e.g. StandardRoundTerminal). Then, the description of a certain Terminal can be progressively elaborated in additional detail by extending what the abstract shape specification means (Round connectors, with two parallel blades separated x inches, etc.) The important concept here is that for two Terminals to work as a Port, they must have the same abstract shape specification and one has to be male and the other female. Figure 4.1 shows a screenshot of Protégé and the ETO that was implemented. In