Ontology-Based Metadata Representation

• A controlled vocabulary is an ontology that simply lists a set of terms and their definitions. Glossaries and acronym lists are two examples of controlled vocabularies.
• A taxonomy is a set of terms that are arranged into a generalization-specialization (parent-child) hierarchy. A taxonomy may or may not define attributes of these terms, nor does it specify other relationships between the terms. XML schemas, RosettaNet and ebXML XML dialects, and STEP standards are taxonomies.
• A relational database schema defines a set of terms through classes (tables, where terms are represented as the rows in those tables), attributes (specified as columns in the tables), and a limited set of relations between classes (foreign keys).
• An object-oriented software model defines a set of concepts and terms through a hierarchy of classes and attributes and a broad set of binary relations among those classes. Some constraints and other behavioral characteristics may be specified through methods on the classes or objects.
• A knowledge-representation system can express all of the preceding relationships, models, and diagrams, as well as n-ary relations, a rich set of constraints, rules relevant to usage or related processes, and other differentiators including negation and disjunction.

Ontologies developed in true knowledge representation systems capture and represent finely granulated knowledge in an unambiguous way, so that this information can be shared and acted on by diverse groups of people and systems linked together by a network. Concepts and resources can be described in multiple ways, depending on point of view, organizational heritage, or role of the individual describing them. A single concept (or description of a concept) may apply to multiple contexts or situations, but the "meaning" associated with that concept may be sensitive to the context or situation. Conceptual knowledge is rarely strictly hierarchical in nature. A lattice, network, or group of networks provides a richer, more complete, and more accurate representation of the complex interrelated concepts and terminology.

Component-Based Ontology Development

• Delivery Layer - web browser (HTTP/XML), PDA, WAP, other native user interfaces, stateless.
• Presentation Layer - data presentation, presentation-related logic, XSL style sheets, XML schemas, stateful.
• rocess and Integration Layer - work flow, application integration, messaging "glue", XML schemas, also stateful and the layer in which state is defined.
• Business or Application Logic Layer - including functionality specific to the applications involved in infrastructure assurance within and across the relevant communities.
• Content and Data Management Layer - data management systems that provide both content management and configuration control, web content management systems, other content libraries, physical data, and information available in file systems reside in this layer.
• Infrastructure - network infrastructure and related management tools, security services, and other systems administration applications.

The capabilities provided within each layer are encapsulated to support highly distributed systems, load balancing, and so forth (as in an n-tiered architecture).

In the same manner, ontologies can be described in terms of the different aspects of an architecture they address for solving different kinds of collaboration or integration problems.

• A role-based ontology defines terminology and concepts relevant for a particular end-user (person or consumer application).
• A process ontology defines the inputs, outputs, constraints, relations, terms, and sequencing information relevant to a particular business process or set of processes.
• A domain ontology, which we might also call a classic ontology, defines the terminology and concepts relevant to a particular topic or area of interest.
• An interface ontology defines the structure and content restrictions (such as reserved words, units of measure requirements, other format-related restrictions) relevant for a particular interface (e.g., application programming interface (API), database, scripting language, content type (such as for a wireless server), user view or partial view - as implemented for a portal, for instance).

This is important because time after time people have demonstrated that building a single, monolithic enterprise data model is costly and fails to deliver the desired utility. Ontologies are, by nature, much larger and more complex than data models, and can take significant effort to build. Thus, component-based ontology construction is the only approach that makes sense.

Just as an artist might apply color to a serigraph in layers, ontologies can and should be developed by user perspective, interface, vocabulary and process, and layered on top of one another until a complete picture emerges. For example, by isolating an interface ontology from the terminology relevant for a domain, it may be possible to limit the changes required when a relational database management system used by an individual organization is upgraded by the vendor to that interface ontology. Cross-organizational communications mismatches can be minimized, if not eliminated, by creating ontologies that reflect the terminology, jargon, and other nomenclature specific to one community, mapping those ontologies by user role to those of another community with differing cultural heritage, and brokering information to be shared among multiple communities utilizing those ontologies and the mappings among them. Brokering across multiple interface ontologies reflecting various metadata standards, XML dialects, and database access methodologies can enable broad accessibility while limiting breakage when any particular interface is changed. In order to utilize ontologies as a basis for collaboration and information sharing for infrastructure assurance purposes, issues such as scope, interoperability among the various engineering and scientific disciplines, interrelated architecture layers, configuration management and other issues must also be considered.