Today XML is a common format supporting interoperability and information exchange between systems in the modeling and simulation field. Although XML enables systems to agree on a common syntax and understand the exchanged information, systems can misinterpret them due to their di↵erent conceptualizations of the domain of interest. In this paper, we present a framework for automatic translation of XML simulation models which follow the High Level Architecture (HLA) object model template specification, into OWL ontologies. In OWL ontologies the semantics of information is formally defined. It provides the basis for interoperability and information exchange between simulation systems on semantic level.
One of the major problems in the modeling and simulation (M&S) field is to
improve interoperability and reusability of systems, especially when systems are
distributed, autonomous and heterogeneous [
In WISE the information to be exchanged is described in a XML-based
common representation which follows the High Level Architecture (HLA) Object
Model Template (OMT) specification [
The rest of the paper is organised as follows. Section 2 presents the background and the related work. In section 3 we describe our strategy for translating the XML models of simulation systems into OWL ontologies. We evaluate and discuss the quality of the ontologies generated from XML models in section 4. In the end we present our conclusion and the future work.
The M&S community has focused on technical layer for interoperability between
systems [
WISE goes beyond the standardized solutions. The focus of system integration is switched from implementation details to the flow of information. The integration platform is seen as an information infrastructure. It is responsible for collecting, translating and delivering information. Each system only needs communicate with the infrastructure. The engineer who builds a connection of a system to the information infrastructure, manually defines the mappings between the model of the information the system needs, to a common model. The WISE currently includes the common models for command and control information in military, real-time simulation, and emergency alerts and public warnings for the civil domain.
In WISE the information exchange models still follow the HLA OMT syntax specification, and are implemented in XML. Since the semantics of information exchange is not formally defined in the XML models, it is not possible to provide formal automated verification of the manual mapping, and/or automated support in defining the mapping. The correctness of the connection depends completely on the knowledge of the engineer about low-level data structures and his implementation of the semantically correct integration.
Over the last few years the community has found that many challenges in the
area are on higher levels, underlying concepts and models that have to be aligned,
not the implementation questions [
Another direction is to develop complete ontology-based framework to achieve semantic interoperability [Ra04]. To build up a simulation among distributed systems, developers have to develop domain ontologies for the individual systems and an ontology for certain simulation objective. Although there are many methods, tools and guidelines for ontology development, building ontologies is still not a simple task, particularly when engineers have no background knowledge on ontology engineering techniques and/or they have not much time to invest in domain conceptualization. In this paper we propose a strategy for how OWL ontologies can be generated automatically out of the XML models, so that there is no requirement on engineers to developing ontologies.
Several strategies have been proposed for translating XML to OWL or RDF
meta-data (e.g. [
In the case of WISE project, every XML document represents either a model for individual simulation system, or a common model for a simulation domain. No actual data is included in XML documents. All XML documents are validated against an XML schema to verify the structure of the documents. As a result, the adoption of any of the existing strategies is not sucient to produce the intended OWL ontologies in our project. We aim to propose a method focusing on translating XML to OWL on conceptual level. Every XML document is translated into an ontology representing a more specific simulation domain. The XML schema is translated into an ontology that can be considered as the top domain ontology for the M&S field.
The XML model is based on the labelled tree, where the meaning of the
tagsnestings are interpreted by the program undertake on it. The OWL model is
based on the subject-predicate-object structure from RDF/RDF-S, where
objects, their attributes and relations are naturally represented, and the semantics
is specified [
Two kinds of entities present in WISE XML models: objects and events. An object is an entity which persists over time (e.g. ”device”, and ”system”) while an event is an entity which only exists momentarily (e.g. ”act”, and ”interaction”). Every entity, either an object or an event, is translated into a OWL class. Each entity always has a set of properties. Many of the properties are datatype properties, describing relations between individuals and data values. All the datatypes in WISE are user-defined types that always restrict the value of a property to a subset of an existing type, not the build-in ones from XML Schema. They are important in capturing the intended meaning of the elements in the models. For example, the ”HLAfloat32LE” is a HLA standard datatype: <float description=”Single-precision floating-point number.” name=”HLAfloat32LE”/> . They are translated to RDF datatype classes.
Either a model for individual simulation system, or a common model for a simulation domain, is described in a XML document. All XML documents are validated against a XML schema to verify the structure of the documents. The XML schema indeed describes very general concepts that are the same across all XML object models. It defines what object is, what event is, their general properties, datatypes specific in simulations, etc. It supports semantic interoperability between the XML models of more specific simulation domains. Therefore, the general model descried in the XML schema can be considered as a top domain ontology for the M&S field. Table 1 gives the principle mapping rules for the translation of the XML schema to the OWL top domain ontology.
schema into the top domain ontology. This is a one time translation when all XML documents share the same schema. A produced XSLT stylesheets can be used by any XSLT processor to automatically generate the desired ontology. The second step is to translate the source XML document to an domain ontology. Not all schema constructs defined in the XML schema appear in every XML document. Since each XML document contains a di↵erent set of schema constructs, XSLT stylesheet for translating each XML document is di↵erent. A configuration file maintains the XPath expressions for each kind of OWL expressions in the top domain ontology, including classes, properties and datatypes. If an XPath expression is evaluated as a valid XPath in the source XML document, a corresponding XSLT stylesheet is generated based on the manually defined mapping rules. In the end, the produced XSLT stylesheet is used to automatically generate the domain ontology from the source XML document.
The goal of the work is to capture the semantics of exchanged information
between simulation systems in XML models and represent them formally in OWL
ontologies, so the focus of our evaluation is to verify and validate the
structure and semantics of the generated ontologies against XML data sources. One
proper method to perform this evaluation is relying on domain expert assessment
against a set of criteria [
The results from the assessment show that the translation process provides accurate conceptualization during automatic translation of XML object models into OWL ontologies. The assessment also shows that the resulted ontologies are consistent. With regard to completeness, the expert ’fully agrees’ that the domain of interest is appropriately covered in the resulted ontologies and is ’neutral’ about any implicit knowledge in XML object models. The latter can be explained by the fact that the expert was also ’neutral’ about his level of expertise in the simulation domain. However, the results still show soundness of the translation process and the mapping rules. Regarding clarity, the expert found no ambiguity in the names of classes and properties and that naming conventions were properly applied. However, the expert was ’neutral’ about the ease of understanding of the conceptualization of the constructed ontologies. Thus, more e↵ort can be made to improve the descriptions of classes and properties and their clarity level. Finally, the expert ’agrees’ that the resulted ontologies can be adapted to di↵erent usages but comments that it is dicult to judge without being able to evaluate the use of the constructed ontologies within their applications.
In this paper we presented an e↵ort to enable interoperability and integration in the M&S field on the semantic level. XML is the common format for information exchange between systems in the field. We proposed the method for automatically translating XML models in the domain into OWL ontologies. The translation intends to capture the semantics of exchanged information in the Accuracy: determines if the asserted knowledge in the ontology agrees with Result the expert’s knowledge about the domain. A higher accuracy comes from correct definitions and descriptions of classes and properties. 1. Are [rdfs:Datatype]s well structured and do they properly represent the 5 datatypes in XML object model? 2. Are [owl:Class]s well structured and do they properly represent the entities 5 in XML object model? 3. Are [owl:ObjectProperty]s well structured and do they properly represent 5 the possible relations between defined datatypes? 4. Are [owl:DatatypeProperty]s well structured and do they properly represent 5 the attributes of the defined datatypes, and entities? 5. Are [owl:AnnotationProperty]s well structured and do they properly provide 5 descriptions about the defined entities and their attributes? Consistency: describes if the ontology does not include any contradictions. Not only asserted knowledge must be logically consistent, but also the formal and informal descriptions in the ontology should be consistent 6. Is there any logical contradictions inferred in the constructed ontologies. 1 e.g. by running a reasoner? 7. Is there any other contradictions, e.g. the documentation and comments of 1 an entity should be aligned with its definition in ontology? Completeness: determines if the domain of interest is appropriately covered. 8. Are all the entities and datatypes described in XML object model repre- 5 sented in the ontology? 9. Is implicit knowledge in XML object model captured by the resulted ontol- 3 ogy? Clarity: measures if the resulting ontology communicates the intended meaning of the defined terms. 10. Is it easy to understand the conceptualization of the resulting ontology? 3 11. Are the names of classes and properties unambiguous? 5 12. Are the descriptions of classes and properties unambiguous? 4 13. Are the naming conventions properly applied to classes and properties? 5 Adaptability: measures how far the ontology can be adapted to anticipated usages. The resulting ontology should o↵er the conceptual foundation for a range of anticipated tasks 14. Could I apply the constructed ontologies in anticipated M&S tasks? 4 15. Could I extend or specialize the resulted ontology monotonically, i.e. with- 4 out the need to remove axioms? XML models and represent them formally in OWL ontologies. The evaluation has showed that the ontologies generated by the automatic translation successfully capture the semantics of the information and correctly represent them. One direction of our future work is to develop algorithms and methods for automatic integration support. When the semantics of exchange information is formally defined in OWL ontologies, it is possible to provide automated support for defining integration and formal automatic verification of manual integration. We thank Kurt Sandkuhl for comments on the project. We also acknowledge the technical support of Saab Training Systems AB.