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. 1 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 sender's 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 recipient's 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.

Fig. 1: Data exchange in the real estate sector

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. The "complete CORE data field catalog" is a subset of the complete data field catalog. It only incorporates all core data fields of the complete data field catalog.

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
  • Internal car parking spaces
  • Warehouses, halls, logistics
  • Production
  • Hotels
  • Industry
  • Residential
  • undefined
  • Other uses

Where possible, existing lists of attributes (e.g., ImmoScout, IPD, ISO, etc.) are accessed and reference is made to the respective source. 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 V 1.1:

Tab. 1: Topics according to gif-IDA
Topics
Number/ area
Fittings
Construction/ refurbishment
Management
Geographical information
Leasing/ term
Capital/ amounts
Master data
Contract
Condition
Book entries