The ReferenceType NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2. The inherited BrowseName Attribute is used to specify the meaning of the ReferenceType as seen from the SourceNode. For example, the ReferenceType with the BrowseName “Contains” is used in References that specify that the SourceNode contains the TargetNode. The inherited DisplayName Attribute contains a translation of the BrowseName.

The BrowseName of a ReferenceType shall be unique in a Server. It is not allowed that two different ReferenceTypes have the same BrowseName.

The IsAbstract Attribute indicates if the ReferenceType is abstract. Abstract ReferenceTypes cannot be instantiated and are used only for organizational reasons, for example to specify some general semantics or constraints that its subtypes inherit.

The Symmetric Attribute is used to indicate whether or not the meaning of the ReferenceType is the same for both the SourceNode and TargetNode.

If a ReferenceType is symmetric, the InverseName Attribute shall be omitted. Examples of symmetric ReferenceTypes are “Connects To” and “Communicates With”. Both imply the same semantic coming from the SourceNode or the TargetNode. Therefore both directions are considered to be forward References.

If the ReferenceType is non-symmetric the InverseName Attribute shall be set. The InverseName Attribute specifies the meaning of the ReferenceType as seen from the TargetNode. Examples of non-symmetric ReferenceTypes include “Contains” and “Contained In”, and “Receives From” and “Sends To”.

Any subtype, either directly or indirectly of a concrete ReferenceType s hall not change the Symmetric Attribute definition of its parent type.

References that use the InverseName, such as “Contained In” References, are referred to as inverse References.

Figure 15 provides examples of symmetric and non-symmetric References and the use of the BrowseName and the InverseName.

Figure 15 – Symmetric and Non-Symmetric References

It might not always be possible for Servers to instantiate both forward and inverse References for non-symmetric ReferenceTypes as shown in Figure 15. When they do, the References are referred to as bidirectional. Although not required, it is recommended that all hierarchical References be instantiated as bidirectional to ensure browse connectivity. A bidirectional Reference is modelled as two separate References.

As an example of a unidirectional Reference, it is often the case that a signal sink knows its signal source, but this signal source does not know its signal sink. The signal sink would have a “Sourced By” Reference to the signal source, without the signal source having the corresponding “Sourced To” inverse References to its signal sinks.

The DisplayName and the InverseName are the only standardised places to indicate the semantic of a ReferenceType. There may be more complex semantics associated with a ReferenceType than can be expressed in those Attributes (e.g. the semantic of HasSubtype). This standard does not specify how this semantic should be exposed. However, the Description Attribute can be used for this purpose. This standard provides a semantic for the ReferenceTypes specified in Clause 7.

A ReferenceType can have constraints restricting its use. For example, it can specify that starting from Node A and only following References of this ReferenceType or one of its subtypes, it shall never be able to return to A, that is, a “No Loop” constraint.

This standard does not specify how those constraints could or should be made available in the AddressSpace. Nevertheless, for the standard ReferenceTypes, some constraints are specified in Clause 7. This standard does not restrict the kind of constraints valid for a ReferenceType. It can, for example, also affect an ObjectType. The restriction that a ReferenceType can only be used by relating Nodes of some NodeClasses with a defined cardinality is a special constraint of a ReferenceType.