1 Sender-recipient model according to gif

1.1 General

Data exchange in accordance with gif-IDA involves a sender, recipient, IT systems, and data that is exchanged between the sender and recipient. The following definitions are applied in accordance with Fig. 3 as a basis for the process model on real estate data exchange.

1.2 Sender

According to gif, a sender within the sender-recipient model is the owner of an IT system in which data is generated, further processed, and sent. The senders IT system is referred to as the delivery system (delivery system).

1.3 Recipient

According to gif, the recipient within the sender-recipient model is the owner of an IT system in which data sent by the sender is received and further processed. The recipients IT system is referred to as the target system (target system).

1.4 Data field

A data field contains information to be exchanged between the sender and recipient. The data field can be identified by its format (e.g., text), and position within a data record that is exchanged between the sender and recipient. A data field (e.g., size of property) is assigned to one or more data objects in each case (e.g., asset). The data fields are divided into core fields and can fields. According to gif-IDA, CORE data fields are data fields that have to be transmitted between the sender and recipient within a process of real estate data exchange. All core data fields according to gif make up the complete gif-IDA CORE data field catalog. Can fields are data fields that may optionally be transmitted between the sender and recipient (see section 1.6).

1.5 Subsets

A subset is a set of individual data fields (core and can fields) defined for a process, which are exchanged between the sender and recipient. Process-specific subsets have been developed by gif given their greater practical relevance. A data field may occur in several subsets (see section 3). A core subset is a subset of a subset. The core subset contains all core data fields of a subset. For an IT system to be granted certification for a process in the exchange of real estate data according to gif, at least all core data fields (core subset) have to be transmitted AND read.

1.6 Rule Sets

For each subset, gif-IDA defines which data fields are to be transferred as mandatory (core) and as can (optional) fields between sender and recipient on the basis of the role
model. In practice, the distribution of functions between sender and recipient and the maintenance of the data fields varies widely.
For this reason, sender and recipient must be allowed to agree optional contents on an individual basis without compromising set quality standards. The obligation to deliver
optional fields can be stored in defined rules (rule sets). If rule sets populate optional fields of the subset with delivery obligations, these fields become mandatory (core) fields in the respective sender and recipient context. The rule set is thus a filter on the optional fields of a subset. This makes all agreed contents clearly identifiable in terms of both contract and technology. The corresponding definitions are stored in separate XSD files, which are read together with the XSD definitions of the subset concerned.

1.7 Complete data field catalog

The complete data field catalog according to gif-IDA incorporates all data fields (core and can data fields) in the individual subsets.

1.8 Attribute

Attributes as defined in this guideline are the pre-defined amounts and/or content that a data field may assume. Using standard attributes should ensure a high standard of quality when exchanging data. In this way, for example, the attributes of Residential or Office are stored with the type of use data field.

1.9 Lists of attributes

The list of attributes includes all attributes that a specific field may assume. Firstly, it has to be complete, in other words even uncommon attributes are entered in the list and secondly, the elements of the list have to be disjunctive, i.e., without overlap. A list of attributes only permits users to select between pre-defined attributes or options when entering data in a data field. In IT terms, this is referred to as a pull-down menu. The value in a list of attributes is transferred using a code. For example, the list of attributes of the data field type of use for the smallest leasable rental unit comprises the following attributes:

• Office
• Leisure
• Retail
• Gastronomy
• External car parking spaces
• Garage, underground car park
• Warehouses, hall, logistics
• Production
• Hotel
• Industry
• Residential
• General commercial
• Social purposes (space)
• Social purposes (number)
• Cellar/ archive
• Other (number)
• Other (space)
• Not defined

Where possible, existing lists of attributes (e.g., ImmoScout, IPD, ISO, etc.) are accessed and reference is made to the respective source. If the sender and recipient do not follow gifs recommendation, each use of a different source must be agreed and disclosed on the basis of the permissible definitions. All lists of attributes used in gif-IDA can be seen in Annex H.1.

1.10 Topic

A topic combines data fields of different subsets based on substantive criteria. A data field can only be assigned to one topic. For example, the size of property at the level of the asset and the leased space at the level of the rental unit are included in the topic of Area. By sorting the data fields of all subsets by topic, it is possible to check the completeness of all topics.
The following topics have been applied in gif-IDA :