One of the major objectives of SEDRIS is to provide a mechanism for unambiguous environmental data interchange. To accomplish this objective, SEDRIS developed a data representation model (DRM) encompassing all the data requirements of synthetic environments used in every type of simulation application. The data contained in the SEDRIS DRM covers every environmental domain - terrain, ocean, atmosphere and space. Prior to SEDRIS, projects attempting to provide an environmental data interchange mechanism focused on development of a format for the interchange medium. Unfortunately, a format-focused approach led to ambiguous data, since the underlying meaning and relationships of the data could not be captured with just a description of the data's format. The SEDRIS DRM provides not only a clear description of the data, but also defines the relationships between the data that are critical to ensuring correct interpretation by users.
A data representation model (DRM) is a description used to provide identification of all data elements within a system, including their attributes and the logical relationships between data elements. In object-oriented terminology, this is viewed as a class hierarchy, and described through a graphics-based design tool. Each major type of data with important or explicit relationships is captured to show its logical relationship to other types of data. A DRM is not an implementation of a database, but a depiction of the types of data within the system. The SEDRIS DRM is described by an associated class dictionary that provides information about each type of class, its attributes, and its logical relationships. SEDRIS also employs a set of "constraints" that place restrictions on the practical use of specific elements of the DRM.
The DRM consists of a set of classes, together with supporting primitive data structures. The classes express the organizational structure of the data being described - that is, its data representation - while the primitive data structures (also called data types) define the fundamental data elements that are used to specify the classes. The DRM also specifies the formal relationships between classes. All this information (i.e., classes, fields, and relationships) can be thought of as a specialized language with its own grammar. This specialized language serves to minimize differences of interpretation in the DRM.
The SEDRIS DRM uses a specific notation to provide a shorthand method to depict the information necessary to describe the data elements, their attributes, and the logical relationships between data elements. This notation allows graphical presentation of the DRM in a clear manner, while also providing a means to capture fully the design of the data. The DRM is a representational scheme, not a format, although a DRM can be easily mapped to a format, and in fact has one - the SEDRIS Transmittal Format (STF).
The SEDRIS DRM is described using an extended form of Unified Modeling Language (UML) notation. For the most part, the notation is UML. The UML notation follows the object-oriented methodology for organizing data. The main extensions to UML used by SEDRIS are that (1) abstract classes are shaded, and (2) fields of classes are not normally shown on SEDRIS class diagrams.
Classes in an object-oriented data model (rather than a DRM) are an abstraction of real-world "things" found in the problem domain, and are described using real-world terminology. Using this modeling concept, one might expect to see such classes as Tree, Tank, and Building in the SEDRIS DRM, if it were a data model rather than a data representation model. However, that is not the case -- the problem domain of SEDRIS is the representation of the real-world environment. This representation is accomplished through the use of DRM constructs with the ability to specify the data necessary to produce both visual and non-visual representations of environments. Consequently, one set of classes in the SEDRIS DRM is the family of "Geometry" classes, such as <Point>, <Line>, and <Polygon>, which provide information that can be used to render a visual scene.
Consider for example, a road. One data provider concerned with renderable geometry might represent a road as a collection of texture-mapped polygons, and would therefore represent the road as a collection of <Polygon> instances in SEDRIS, where the entire collection is tagged with a <Classification Data> identifying it as a road. However the data thus provided by the road's visual representation, while suited to rendering the road in a visual scene, is not suited for data providers whose applications are required to recognize a road and make decisions based on its presence in the environment. For example, where does the road begin and end? What other roads, if any, cross it, and where are the crossings?
Topology information provides connectivity and adjacency information in an environment, and is represented explicitly in SEDRIS by topology classes. To represent a road as a "thing" with associated topological information, a data provider can represent it as a <Feature>, which by definition has associated topological information. A data provider might choose to represent the road in this example as a <Linear Feature>, where each segment of the road is a separate <Feature Topology> instance, in this case, a <Feature Edge>. Again, the <Linear Feature> would be identified as a road by the presence of appropriate <Classification Data>. The topology relationships assist the reasoning models by providing explicit information, instead of performing calculations to derive the information.
If a data provider wished to provide both representations, indicating that they corresponded to the same "thing", this would be done by providing both representations and joining them with an association relationship to indicate that each is an alternate representation of the other.