Knowledge discovery is essentially the process of extracting semantic concepts and relationships from domain resources within a particular domain. Ontologies are the de facto standard for representing knowledge of a system [1]. The framework and components of ontologies are based on established, yet evolving W3C standards. Ontologies usually are comprised of concepts, relationships and axioms. Concepts are abstractions of related attributes that form the basic building blocks of a semantic model. Relationships can be between two concepts or between a concept and a data-type. Axioms consist of asserted knowledge that can be represented as a <subject, predicate, object> triple. Logic-based reasoners can be used to infer new knowledge in an ontology.
Although ontologies are valuable assets in system modeling, testing and analysis, the process of manually creating an ontology for a complex system is inherently tedious and error prone. Existing methods of knowledge discovery and ontology creation usually are based on text mining of a data corpus for that domain. XML-based systems capture the structure and syntax of all necessary and meaningful elements in a XML schema, which therefore is a useful starting point for semantic analysis. In such systems, XML schemata have been shown to be a valuable resource of semantic data [2]. Command and Control systems in the military context support various functions, including commanding of forces and also receiving and interpretation of situational awareness reports. To perform these functions, most C2 systems are modeled using XML schemata e.g. Coalition Battle Management System (C-BML) [3], Military Scenario Definition Language (MSDL) [4], and National Information Exchange Model (NIEM) [5], which represent the systems' structural and syntactic framework. These systems use and exchange XML documents that are based on XML schemata.
XML often is used as the exchange mechanism in the command and control domain [6]. Given the increasing number of XML-based systems in the C2 domain, an automated framework that leverages semantic information in the XML schema and creates a draft ontology would be a useful tool. Domain experts can refine and populate the draft ontology using concept hierarchy and basic domain relationships. For large XML based systems, this process of creating a draft ontology saves valuable time and avoids errors common to the alternative tedious, manual process. In contrast to existing techniques used to map a XML schema to an ontology, the mapping proposed in this paper highlights the need to map schema element (xs:element from here forward) to an ontological concept. This avoids the usual approach of mapping XML complex types to concepts that could lead to unnecessary ontological complexity. In addition, this paper proposes a novel Part of Speech tagging method to extract domain relationships from well-annotated XML schema.
Most existing work on mapping a XML Schema to an ontology (e.g. [7], [8] ) is based on mapping XML schema complexType (henceforth referred to as xs:complexType) to an owl:class. This mapping can lead to problems for the following reasons: 1. A "simpleType" definition is sufficient to define a semantic concept. In the command and control domain, for example, it is possible to define an element called "Unit-Name," which is of a "simpleType" string (with string restrictions). There is sufficient semantic information in this definition to create a distinct ontological concept. When this level of abstraction of concepts is ignored and only complex type definitions are considered as semantic concepts, the resulting ontologies will contain significant modeling gaps for any useful analysis. 2. By design, XML parsing only allows elements associated to a complex type to appear in valid XML files. XML schemata can contain complex type definitions that are never associated to an element definition. When concepts are mapped to complex types, the resulting ontology will likely include concepts that will never appear in the XML document. This unnecessary complexity is counterproductive to efficient semantic modeling in design and analysis.
Bohring et al. [9] recognize the value of semantic concepts being mapped to <xs:element> definition. However, this mapping is done only for <xs:element> definitions that are not leaf nodes and have at least one attribute definition. The approach in [9] fails to consider valid semantic concepts that are simple literal definitions. In addition, ontologies have been designed so that datatype properties can be mapped to XML schema datatypes [10]. Therefore, the resulting mapping of simple xs:element to owl:DatatypeProperty using that approach would be inconsistent with standard practice of ontology design. Yang, Steele, and Lo [11] describe an ontology-based mapping between XML and ontology (bi-directional) that focuses on limiting loss of information in the bi-directional mapping.
Existing work ignores semantic information pertaining to domain relationships that are present in well-annotated XML schema annotations. By design, the purpose of XML annotations is to capture description of elements, which are often described in relation to other elements. For instance, consider the XSD annotation for the element <xs:EventStatus> of the C2 domain in Figure 1.
The mapping process takes as input a sufficiently annotated XML schema, which we define as any XML schema that contains the following:
a) The schema provides annotations for most elements using descriptive domain terminology b) Annotations referencing elements defined in the schema use a consistent naming convention.
As an example of the latter, if the schema defines an element as "ReporterWho" then any annotation referring to this element must do so in a consistent way, i.e., the reference can be extracted by simple operations (e.g., removing spaces, pruning special characters, etc.)
The system components and relationships between the components are illustrated in Figure 2 below. Pre-processing the XML schema: Our approach maps the ontological concept name to the name of the element in the XML schema. XML schemata allow for multiple elements to have the same name. More often than not, the same name is used (e.g. <xs:element name="ID"/>),specially when defining identifiers and other common elements. Even though the same name may exist in different element definitions, as long as their context is different they are semantically different concepts. In order to disambiguate between elements with the same name, we propose a preprocessing step that concatenates the parent complex type name to the name of the element using a delimiter. For elements that do not have a parent complex type, an iterating place-holder name can be used (e.g. "Parent i ") Because XML schema rules require that all xs:complexType have unique names in the schema, this pre-processing step ensures that element names (and therefore concept names in the ontology) are unique in the XML schema. The preprocessing step performs the disambiguation technique to all elements, and not only to the redundant elements. This is specifically convenient because capturing the schema structure in the ontology could be useful to other ontological processes (e.g. ontology matching that uses XML schema structure). The pre-processing step is illustrated in Figures 3 and 4 below. [9]. Therefore, if an element "element1" is defined as having type "complexType1" and the definition of "com-plexType1" includes an "element2" with max-occurs=unbounded, then the cardinality between the concepts "element1" and "element2" is 1…∝
Mapping 2: Element hierarchy to concept hierarchy: Nayak and Wina [12] have noted that XML schema contains element definitions in a hierarchical structure. They employ structural information in XML schemata to define clusters based on semantic similarity. Varlamis and Michalis [13] note that XML schema relationships support inheritance relationships between elements. The most common method to create an inheritance relationship in a XML schema is to use xs:extension so that one element can extend another. This mapping step also identifies all occurences of "abstract=true" in the definition of an element, computing it as indication of a inheritance relationship. It should be noted that existing mapping methods ignore the presence of inheritance using of "abstract=true" because xs:element is not mapped to ontological concept.
Mapping 3: Schemata composition to 'partOf' and 'kindOf' relationships: In XML schemata an element defined as a complex type is composed of other elements. Elements can be composed using 'All', 'Sequence' and 'Choice' indicators. All elements in 'All' and 'Sequence' groupings are mapped to a 'isPartOf' OWL object property and all elements in the 'Choice' composition are mapped to a 'isKindOf' OWL object property. The following two examples illustrate the mapping from schema composition to OWL object properties.
<xs:element name="Task" type="taskType">
The definition of 'taskType' is composed of other elements as follows:
In the definition above, the element 'Task' is composed of 'Who', 'When' and 'Where' using the sequence composition. The mapping proposed in the paper will leverage the sequence composition to establish the following properties:
• 'Who' isPartOf 'Task'
• 'When' isPartOf 'Task'
• 'Where' isPartOf 'Task'
The element 'Where' is composed of 'AtWhere' and 'RouteWhere' using the choice composition. The mapping proposed in this paper will leverage the choice composition to establish the following properties:
• 'AtWhere' isaKindOf 'Where'
• 'RouteWhere' isaKindOf 'Where' Step1: Identifying all concepts in the annotation: This is done by identifying all words tagged as nouns or proper nouns (NN, NNS, NNP, NNPS) by the POS tagger. The concepts are added to a vector as follows:
Step 2: Identifying predicates for the relationship: Starting at the beginning of the annotation, a concatenation of adjectives (JJ), Pronouns (WP), and prepositions (IN) is created until concept C i is encountered. This concatenation forms the predicate of the domain relationship. These predicates are added into the vector as:
Each concept C i will now have an accompanying predicate. If pred i has only one word and is a coordinating conjunction (e.g. "and") then pred i-1 is assigned to pred i . This is due to the presence of a coordinating conjunction between <xs:complexType name="taskType"> <xs:sequence> <xs:element name="Who" type="whoType"/> <xs:element name="When" type="whenType"/> <xs:element name="Where" type="whereType"/> </xs:sequence> </xs:complexType> <xs:element name="Where" type="whereType> <xs:complexType name="whereType"> <xs:choice> <xs:element name="AtWhere" type="AtWhereType"/> <xs:element name="RouteWhere" type="routeType"/> </xs:choice> </xs:complexType> two concept names C1 and C2, meaning that whatever predicate applied to C1 also applies to C2.
Step 3: Creating the domain relationship: If the annotation is for element E1, then for each concept in V concepts the following domain relationship (owl:objectProperty) is created: <subject, predicate, object> = < C i , str_concat(hasAs,pred i ), E1 >
As an example consider the following annotation: Based on the technique described above, the following domain relationship is created: <Task hasAsReferenceTask TaskWhatRef> Note: For the sake of clarity of illustration the schema as it appears before pre-processing is shown in Figure 5.
The mappings described in the steps above are illustrated in Figure 6. In order to provide interoperability on the semantic level, C2SIM will require ontological support for formalizing semantics and for the design and analysis of networked C2 and simulation systems. Early work on the need for and future of semantic C2SIM is described in [21]. C2SIM development is based on complex XML schemata that have been developed in Phase 1 standardization effort of C-BML [3] and MSDL [4]. These XML schemata have been found to be complex [22] because the design intended to capture the full expressivity of the underlying sophisticated data model. Adopting a manual process to create an ontology from these schemata can be tedious and error-prone. The method proposed in Section 3 has been applied to the C-BML Phase1 schema [3]. Statistics of the XML schema used to create the draft ontology are presented in Table 1. The pre-processing step, described in section 2, disambiguated element names so that concepts can be accurately mapped to elements in the XML schema. The draft ontology created by this method captures a conceptual hierarchy consistent with an intuitive understanding of C2SIM. The domain relationships are descriptive and useful for capturing business rules. The statistics of the ontology created are shown in Table 2. At the time of this writing, we are conducting an evaluation of draft ontology to validate these preliminary results. The evaluation involves the use of subject matter experts (SMEs) to evaluate the draft ontology by checking it against domain documents and their own expertise. The initial results, while still anecdotal, suggest that the resulting ontology is consistent with SME evaluation of domain documents.
The proposed method extracts domain concepts and relationships from well-annotated XML schema. Potential approaches to improve the quality and resolution of the resulting ontology include the use of domain synonym tables as a means to support identifying concept names in schema annotations. We believe this can account for variants of a name that may be used in the schema annotation. Future work improving our methodology also includes capturing C2 doctrine in the form of axioms, as well as evaluating the use of reasoning to both infer and hypothesize knowledge. In ongoing work [26], we are also investigating the use of structural information in XML schemata to perform ontology matching between two XML based ontologies. Ontology matching of two complex ontologies that have accompanying complex schemata suffers from high computational cost. Finally, we are exploring a tighter coupling between ontology creation and ontology matching by embedding basic XML schema structure in auxiliary ontology artifacts (e.g. annotations).