Intent

An association is a general relation between two or more objects, where at least one of the objects has knowledge of the other one and can access that object’s data and methods. The lifecycle of the associated objects is typically decoupled. The objects can be from different domain models and even managed on different systems - an association is a type of loose coupling.

Associations can be unidirectional, bidirectional or multi-directional. In a unidirectional association, the object that has knowledge of the other object is called the controller, the other one the controlled object. In a bidirectional relationship, both objects know of the other one and can invoke its data and methods. Note that you cannot create an association from an existing INSPIRE class directly, so there can be no bidirectional associations between your class and an INSPIRE class. You will need to create a subtype of the INSPIRE class to add that association.

Multi-directional (sometimes called n-ary) associations connect three or more different objects. They are very complex and we don’t recommend their usage in INSPIRE extensions.

The objects that are related via the association are considered to act in a role with respect to the association, such as an object of type Owner acting in the role hasOwner on a Parcel object. A role can be used to distinguish two objects of the same class when describing its use in the context of the association, such as a Person who may be in a parent and a child role at the same time.

Structure

When using associations, we connect controllers and controlled objects through a simple association, with arrows indicating visibility:

When to use

Associations are very versatile, and have several applicable uses:

1. When the associated objects have different lifespans
2. When associated objects should be re-used many times, e.g. in N:M relationships
3. Generally, when loose coupling of objects is desirable, e.g. when the associated objects are part of different domains or implemented in different systems
4. When coupling objects of two classes, but not more (for that you should instead create new types)

When not to use

Associations should not be used when:

1. Strong coupling is desirable (whole-part relationships, shared lifecycle)

XML Schema Example

A potential schema structure for the association pattern is as follows:

Download the Example Schema

In line 11, we set the Owner element’s substitutionGroup to AbstractFeature. This is mandatory to allow objects of this type to be included in the container, a wfs:FeatureCollection. In lines 28 and 29, we use gml:ReferenceType as the type of the properties, instead of the actual types the references point to (which could be CadastralParcel and Owner). This means we lose some information in the XML schema. There are several ways to encode this information, such as using annotations or optional attributes of the xlink, but none of them were standardised in INSPIRE.

Please note that we create a new Owner class instead of re-using one of the metadata classes such as CI_ResponsibleParty, since the latter cannot exist as a stand-alone member of a FeatureCollection.

XML Instance Example

Instances using this pattern are usually encoded as follows:

Download the Example Instance

We use gml:ReferenceTypes to encode the association. Such references use XLinks to point to any local or remote resource with a resolvalbe URL. In this case, we define in-document anchors such as #owner_1 to point to any element identified by an id.

Implementation Considerations

This section provides information when and how this pattern can be implemented on different types of platforms.

Storage Backend

Association is well-supported by all types of storage backends. Some backends, such as document-oriented databases, have limitations in the way how they enforce referential integrity when such patterns are used.

Download Services

This pattern can be implemented on XML-based platforms without special considerations.

Business Logic

This pattern can be implemented on object-oriented platforms without special considerations.

Consumer Side

Most GIS clients do no have special handling for associations. As an example, associations encoded using xlink:href are usually normal attributes for GIS clients, and not automatically expanded. Similar to Aggregation, ArcGIS can emulate associations via the definition of client-side Relates.