The SEDRIS Data Representation Model
APPENDIX A - Classes
Property Characteristic

Class Name: Property Characteristic

Superclass - <SEDRIS Abstract Base>

Subclasses

This DRM class is concrete and has no subclasses.

Definition

An instance of this DRM class specifies additional information about how to use, interpret, or further specify a <Property> instance or <Table Property Description> instance.

Primary Page in DRM Diagram:

Secondary Pages in DRM Diagram:

This class appears on only one page of the DRM class diagram.

Example

  1. A <Model> instance classified as ECC_BRIDGE has a <Property Value> component representing its length. The <Property Value> component has two <Property Characteristic> components to specify maximum length and length precision:

    The first <Property Characteristic> component specifies:

    meaning EVC_MAXIMUM_VALUE
    characteristic_value {EDCS_AVT_REAL, {EUC_METRE, ESC_UNI, {EDCS_NVT_SINGLE_VALUE, {32767.0}}}}

    The second <Property Characteristic> component specifies:

    meaning EVC_TOLERANCE
    characteristic_value {EDCS_AVT_REAL, {EUC_METRE, ESC_UNI, {EDCS_NVT_SINGLE_VALUE, {1.0}}}}
  2. A <Property Grid> instance containing a <Table Property Description> component with meaning = {SE_ELEMTYPCOD_ATTRIBUTE, {EAC_AIR_TEMPERATURE}} describes air temperature measurements over the specified region. In some locations, no measurements were taken, so a sentinel value (deliberately chosen to lie outside the range of possible data values) is needed to indicate those locations.

    Consequently, the <Table Property Description> instance for EAC_AIR_TEMPERATURE in this example has a <Property Characteristic> component with meaning = EVC_MISSING and characteristic_value of, for example, -10000.

    Any cell data element for this <Table Property Description> instance that has a value of -10000 is therefore interpreted as meaning that the measurement is missing.

    NOTE 1  The <Table Property Description> instance may have other <Property Characteristic> components provided that they have different meaning values. For example, this <Table Property Description> instance may have another <Property Characteristic> component specifying EVC_MINIMUM_VALUE.

  3. A <Property Grid> instance containing a <Table Property Description> component with meaning = {SE_ELEMTYPCOD_ATTRIBUTE, {EAC_SALINITY}} describes water salinity data over the region specified for the grid. However, in this example, part of the grid lies over land, so that water salinity measurements not only were not taken there, but make no sense. A sentinel value (deliberately chosen to lie outside the range of possible data values) is needed to indicate those locations.

    Consequently, the <Table Property Description> instance for EAC_SALINITY in this example has a <Property Characteristic> component with meaning = EVC_NOT_APPLICABLE and a characteristic_value of, say, -1.

    Any cell data element for this <Table Property Description> instance that has a value of -1 is therefore interpreted as meaning that the measurement is not applicable.

    NOTE 2  The <Table Property Description> instance may have other <Property Characteristic> components, provided that they have different meaning values. For example, this <Table Property Description> instance may have another <Property Characteristic> component specifying EVC_MINIMUM_VALUE.

FAQs

Why would a <Property Value> instance require a <Property Characteristic> component?

If a <Property Value> instance has associated with it a valid range of values or a precision value, each of these associated values can be attached to the <Property Value> instance with a <Property Characteristic> component.

However, a <Property Value> instance is not required to have <Property Characteristic> components that specify sentinel values, since they are meaningful only in the context of <Data Table> instances.

Shouldn't a value's range and precision information be part of metadata, such as <Data Quality> instances?

They can be, but metadata information is not readily accessible in software. For example, in an application which plots tabular data, access to information specifying the valid range of values is useful in scaling the plot. As a second example, precision information can be used to determine appropriate round-off when converting between units of measurement.

How do <Table Property Description> instances in the signature of a <Data Table> instance use <Property Characteristic> instances?

In addition to specifying value ranges, precision, and tolerances, a given <Table Property Description> component of a <Data Table> instance can use a <Property Characteristic> component to specify information that applies to all cells in the <Data Table> instance, such as a sentinel value that flags a special meaning to certain values. A <Property Characteristic> instance can also be used to indicate that a certain property of a <Data Table> instance is in fact constant in this particular instance of the table.

Why are <Data Table> sentinel values needed?

Often <Data Table> instances are incomplete for various reasons. Typically a set of special values is selected to flag missing data. Such special values are selected to be out of the valid range of values for the parameter in question. Since the valid range of a parameter varies by data set as well by <Table Property Description> component, these special values vary accordingly. <Property Characteristic> instances provide a means to associate specific sentinel values and their meanings with a specific <Table Property Description> component of a specific <Data Table> instance.

How can characteristic values for EVC_NOT_APPLICABLE, EVC_MISSING, EVC_VALUE_WITHHELD, EVC_MULTIPLE, and EVC_UNDESIGNATED be used with enumerated EDCS Attributes?

The sentinel mechanism that is often used with numeric attributes use out-of-valid-range values in conjunction with <Property Characteristic> instances for this purpose. The only valid EE codes for a given EA are specified in the EE dictionary. Any non-valid code for the EE (such as a negative value) may be used for a characteristic value.

What are the units of a <Property Characteristic> instance's characteristic_value?

The characteristic_value is measured with the same unit as the <Property> instance that aggregates it.

What is the difference between EVC_MAXIMUM_VALUE, EVC_MINIMUM_VALUE and EVC_UPPER_BOUND, EVC_LOWER_BOUND?

EVC_MAXIMUM_VALUE and EVC_MINIMUM_VALUE are intended to give the nominal or legal range of values for this type of data as opposed to this instance of the data. EVC_UPPER_BOUND and EVC_LOWER_BOUND are intended to supply a tighter bound for the given instance of numeric data. If both sets of characteristics are supplied, then:
EVC_UPPER_BOUND <= EVC_MAXIMUM_VALUE
EVC_LOWER_BOUND <= EVC_MINIMUM_VALUE

Is EVC_UPPER_BOUND the same as the least upper bound for the data? Similarly, is EVC_LOWER_BOUND the greatest lower bound?

Not necessarily. But the tighter the bound the more useful is the information provided. If possible they should be the least upper greatest lower bounds.

How are the EVC_UPPER_BOUND, EVC_LOWER_BOUND values used?

They can be used by the data consumer to supply information for such activities as scaling graphs and checking data validity. When supplied for a <Table Property Description> instance together with EVC_TOLERANCE values, a SEDRIS API implementation may be able to use this information to compress the <Data Table> instance.

Constraints

Component of (two-way)

Inherited Field Elements

This class has no inherited field elements.

Field Elements

EDCS_Value_Characteristic_Code meaning; 1
EDCS_Attribute_Value characteristic_value; 2

Notes

Fields Notes

meaning

The meaning field specifies the semantic represented by the <Property Characteristic> instance.

characteristic_value

The characteristic_value field specifies the data value of the <Property Characteristic> instance.


Prev: Property. Next: Property Description. Up:Index.

Last updated: July 26, 2006 Copyright © 2006 SEDRIS