Interface link types

An interface link type defines an object-to-object relationship common across all object types implementing an interface. Users can specify a description for the interface link and an API name for the interface link type to use as a reference in code. When an object implements an interface with an interface link type, all interface link types on the interface are backed by concrete link types on the object type. Any ontology modifications will validate that the concrete link type matches the parameters specified by the associated link type constrains.

Interface link type creation.

As shown in the example above, to model the relationship between a facility and the airlines it serves, the Facility interface declares an optional one-to-many link type constraint between any object that implements the Facility interface and the Airline object type. This means that if the implementing object type (for example Airport) has a concrete link type to the Airlines object type, that link can be accessed through the interface link type API name.

Link type constraints define the parameters of an interface link type. All implementing object types must have a link that satisfies these constraints if the link type is required. These parameters include the following:

  • Link target type: An interface or an object type.
  • Target: A specific interface or object type.
  • Cardinality: One-to-one or one-to-many.
  • Whether or not the link is required as part of object type implementation.

You should use an interface link target when you want to model the relationship between two abstract object types.

For example, you can use an interface link target to model the relationship between Facility and the Alert where they occur. Because there are several kinds of facilities and several kinds of alerts, it would be impossible to model the connection between the two if you could only use a single object type for each end of the link. Instead, you can model this relationship by defining a Facility interface, an Alert interface, and an interface link on Facility that is set to link to the Alert interface. You can then define an Airport object type that implements the Facility interface and a Flight Alert object that implements the Alert interface. From there, you can define a concrete link type from Airport to Flight Alert to satisfy the Facility interface’s link type.

You should use an object type link target when the relationship between the interface and the target is concrete and the specificity should be enforced by the link type constraint.

For example, you could define a Facility interface that links to the Airlines object type. This interface link would model the fact that no matter what the facility type is, you expect it to have a link to the specific airlines that it serves.

Interface link types can further be specified to have a ONE or MANY cardinality. These cardinalities are analogous to one-to-one and one-to-many modeling, respectively, where the interface link type is the left side of the relation. A ONE cardinality indicates that a concrete object (a row of an object type) should link to exactly one other concrete object. A MANY cardinality indicates that a concrete object can have one or more links to other concrete objects.

You should decide between using ONE or MANY based on the modeling needs for your Ontology. In some cases, it may make more sense to restrict the cardinality of the link to a single object. For example, you may want to model the relationship between a Driver's License and a Person as a SINGLE cardinality link since any given license can only belong to a single concrete individual. If the relationship allows for more flexibility, such as with a Company and its Shareholders, you may want to use a MANY cardinality link to signify that a given company can have one or more concrete shareholders.