# Interface link type constraints An interface link type constraint defines an object-to-object relationship common across all object types implementing an interface. Users can specify a description for the link and an API name for the link type to use as a reference in code. When an object implements an interface with an interface link type constraint, concrete link types on the object type are used to fulfill interface link type constraints. 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 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. ## Link target: Interface You should use a link target of type `interface` 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 constraint. ## Link target: Object type You should use a link target of type `object type` 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. ## Cardinality 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. A `ONE` cardinality indicates that each object implementing the interface should link to one object of the target type. A `MANY` cardinality indicates that each object implementing the interface may link to any number of objects of the target type. 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 each 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 each company can have one or more concrete shareholders.