From XBRLWiki

Revision as of 09:15, 27 February 2013 (edit) Katrin (Talk | contribs) (→Data Point Meta model) ← Previous diff

Revision as of 09:17, 27 February 2013 (edit) Katrin (Talk | contribs) (→Data Point Meta model) Next diff →

---

Revision as of 09:17, 27 February 2013

CEN Workshop Agreement

Status: Working Group Working Draft

Editing rules

Editorial comments should be highlighted as follows: A comment

Text or rules in discussion (white): Some text

Text or rules already aligned (green): Some text

Text or rules to be deleted (red): Some text

Text to be delivered (blue): Some text

Contents 1 Foreword 2 Introduction 2.1 Objective 2.2 Target Audience 2.3 Relationship to Other Work 3 Scope 4 Normative references 5 Terms and definitions 6 Data Point Meta model 6.1 Meta classes of the Data Point Metamodel 6.1.1 Data Point Model 6.1.2 Public Element 6.1.3 Dictionary Element 6.1.4 Dimension 6.1.5 Domain 6.1.5.1 Enumerable Domain 6.1.5.2 Non-enumerable Domain 6.1.6 Member 6.1.6.1 Defined Member 6.1.6.2 Non-defined Member 6.1.7 Dimensioned Element 6.1.7.1 Dimension Set 6.1.7.1.1 Family 6.1.7.1.2 Perspective 6.1.7.2 Data Point 6.2 Perspectives of the Data Point Metamodel 6.2.1 Versioning Perspective 6.2.2 Framework 6.2.3 Taxonomy 6.2.4 Table 6.2.5 Dimension Validation Perspective 6.2.6 Module 6.2.7 Table Cube 6.2.8 Presentation Perspective 6.2.9 Hierarchy Perspective 6.2.10 Hierarchy 6.3 Data Point Metamodel Constraints 6.3.1 General constraints 6.3.2 XBRL specific constraints 6.3.3 Data warehouse specific constraints

Foreword

Some text

Introduction

The Data Point Methodology consists of a set of methodical procedures to create a multidimensional data point model that reflects detailed business aspects of supervisory frameworks. The result of the implementation of these procedures is a data point model which provides data structures that can be represented in supervisory tables and underlying regulations that can be interpreted by IT applications. Data point models are created by banking specialists who are highly skilled in understanding supervisory reporting frameworks. This document defines technical requirements on data point models that need to be fulfilled when using data point models (1) for generating data formats for the reporting process or (2) for designing multidimensional database structures for the analysis of supervisory data.

The document intends to support the communication between supervisory experts and IT experts by introducing the concept of data point modelling and its underlying terms.

This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “MUST” (strong recommendation), “SHOULD” (recommendation) and “MAY” (possibility). Organizations wishing to implement this CWA (CEN Workshop Agreement) would be expected to consider all recommendations where the terms "MUST" and “SHOULD” are used.

Objective

A Data Point Model consists of objects that reflect the supervisory data and its relations among each other that can be communicated and understood by computers. The objects of a data point model described in this document facilitate the ease of understanding of the data structure for technicians and reflects the rules to be met when using a data point model as basis for the generation of a data format or as basis for analysis purposes.

Target Audience

This document is being created to support Information Technology (IT) experts in the transfer of content from regulatory reporting to IT systems. It assumes that the reader has a working knowledge of the XBRL 2.1 and the XBRL Dimensions 1.0 Specifications as Data Point Models are being used as basis for generating XBRL taxonomies. Furthermore basic knowledge about Business Intelligence is assumed to understand the rules to be followed when designing multidimensional database structure for data warehouses.

Relationship to Other Work

Some text

Scope

The Data Point Methodology has been defined for the creation of data point models in the context of European supervisory reporting. Data Point Models are published by an European supervisory authority and accompanied by an XBRL taxonomy to reflect the defined data structures in a machine-readable form.

Normative references

• XBRL 2.1
• XBRL Dimensions 1.0

Terms and definitions

There are no formal definitions that are taken from other documents. Comment-04

Data Point Meta model

The data point meta model provides (1) the components for the construction of a formal model that describes sets of data points relevant to European supervisory reporting frameworks, (2) rules on how to combine these components and (3) the meaning (semantic) of the components and relations. Similar to a model construction kit for toys it provides the modelling principles with all characteristics available for use by the modeller. A UML class diagram is used to provide the syntax and semantic to define the meta model for data points by showing the relevant classes and their attributes.

Meta classes of the Data Point Metamodel

Data Point Model

A Data Point Model (DPM) defines structures of data describing the characteristics of the information exchanged in the context of supervisory reporting processes. A DPM consists of a dictionary of business concepts and their properties which are represented in tables. It identifies the content of each data point by its granular components with a semantic meaning and its relation to other data points.

From an IT perspective a DPM can be interpreted by IT applications which enable (1) a generation of data formats for the reporting process or (2) the design of multidimensional database structures for the analysis of supervisory data, i.e., in data warehouses.

References:

meta class	multiplicity	description
Public Element	one or more	References the collection of Public Elements owned by a Data Point Model.

Public Element

A public element is a generalization of a concept of the model. It is identified by a code and consists of an appropriate label. Public elements have two additional attributes giving information about the date of creation and modification. Each public element is owned by an institution or an organization. The owner needs to be made explicit in the data point model. Public elements are abstract and need to be specified by its concrete sub classes like frameworks, tables etc.

XBRL equivalent: xbrli:item enhanced by the DPM specific XML attributes model:creationDate and model:modificationDate
References:

meta class	multiplicity	description
Data Point Model	one or more	References the Data Point Model owning the collection of Public Elements.

Dictionary Element

Dictionary Elements are abstract elements that build the basis of the core concepts of a data point model like dimensioned elements, dimensions, domains and domain members. They are derived from public elements and may define a currency period to enable a filtering of obsolete elements by applications. The currency period is defined by two optional attributes validFrom and validTo which should ease the maintenance of elements of the data point model in the course of time.

Comment-06

Superclass: Public Element
XBRL equivalent: xbrli:item based on the definition of the public element with two additional XML attributes model:fromDate and model:toDate.

Dimension

A dimension is a data set to one characteristic area which is composed of individual and non-overlapping data elements. In the context of a data point model dimensions are used to group information in a meaningful way. Dimensions are used to define "by" conditions and provide structured information to describe a data point in detail. A dimension can refer to a enumerable domain with a definite number of elements or an innumerable domain where the members are defined by a data type and some additional constraints.

Superclass: Dictionary Element
XBRL equivalent: Abstract xbrli:item in the xbrldt:dimensionItem substitution group
References:

meta class	multiplicity	description
Domain	exactly one	References the Domain associated with a Dimension.

Domain

A Domain is a classification system to categorize items that share a common semantic identity. A domain provides therefore an unambiguous collection of items in a value range. The items of a domain can have a definite, and therefore countable, number of items, or an infinite number of elements that follow a specific pattern.

Superclass: Dictionary Element
References:

meta class	multiplicity	description
Dimension	exactly one	References the Dimension associated with a Domain.

Enumerable Domain

An enumerable domain is a subclass of domain that specifies a definite number of members.

Superclass: Domain
Contained elements: Member Set
XBRL equivalent: xbrli:items that form a discrete, countable and finite set of members to be referenced by explicit dimensions with dimension-domain arcs.Comment-11
References:

meta class	multiplicity	description
Member Set	exactly one	References the set of members owned by a Enumerable Domain.

Non-enumerable Domain

A non-enumerable domain is a subclass of domain that specifies an undefined number of members in the domain. The non-enumerable domain defines syntactic constraints on the values of the members, i.e. a data type or a specific pattern.

Superclass: Domain
XBRL equivalent: A typed dimension that defines syntactic constraints on the set of members by an XML schema element. The XML schema element is the content of its xbrldt:typedDomainRef attribute.

Member

A member is the actual value that is given to a dimension. Members are grouped in domains. Members in a domain share certain semantic identity.

Superclass: Dictionary element
XBRL equivalent: Each one of the possibilities in the domain of a dimension.

Defined Member

A defined member is discrete and countable. A number of these members can be explicitly listed in an enumeration.

Superclass: Member
XBRL equivalent: xbrldi:explicitMember which content is a QName of an xbrli:item referenced in a dimension-domain arc of an explicit dimension.Comment-12

Non-defined Member

A non-defined member is defined by syntactic constraints on a possible value, not the value itself.

Superclass: Member
XBRL equivalent: XML element which follows the rules of the XML schema element which is the content of the xbrldt:typedDomainRef attribute of a typed dimension.

Dimensioned Element

Dimensioned elements represent the nature of the data with a fixed and unchangeable meaning. Dimensioned elements are strongly related to the underlying data type. Mostly they are numeric and quantitatively measurable to be used for calculations and aggregations but they can be also reflect boolean or date values. A dimensioned element is the essential part of a data point that can also refer to zero or more dimensions with its according set of members.

• The attribute dataType establishes the set of possible values of the facts reported according to that metric: monetary information, percentages, dates, texts…
• The attribute periodType defines whether the property / amount to be measured corresponds to a specific moment in time (instant type) or whether its nature requires it to be obtained by taking measures during an interval of time (duration type).

Superclass: Dictionary Element
XBRL equivalent: xbrli:item in the sense of a primary item.

Dimension Set

This meta class is a set consisting of dimension elements, which summarizes dimensions in a specific business context.

Contained elements: Dimension
References:

meta class	multiplicity	description
Data Point Model	zero or more	References the collection of Dimensions owned by a Data Point Model.

Family

Families are groups of dimensions only relevant for presentation purposes.

Superclass:Dimension Set
XBRL equivalent:

Perspective

Perspectives represent different criteria of grouping: for financial purposes, for prudential purposes, for statistical purpose. Perspectives, therefore, establish an association between dimensions and families. Comment-13

Superclass:Dimension Set
XBRL equivalent:

Data Point

A Data Point as a financial concept is characterized by defining its basic financial meaning and specifying information of breakdowns (hierarchies) in which it is described in different tables or paragraphs of documentation.

Contained elements: Dimension Set, Dimensioned Element
XBRL equivalent: A valid combination of a primary item with a set of dimension-member pairs defined by an XBRL hypercube.
References:

meta class	multiplicity	description
DimensionedElement	exactly one	References the element to be dimensioned by a set of dimensions with their according members.
Dimension Set	zero or one	References the set of dimensions, each dimension is linked to a domain and one member.

Perspectives of the Data Point Metamodel

Versioning Perspective

A Data Point Model combines the reporting regulations for several specific scopes of information (solvency information, financial information…) summarized in one or more Frameworks. The name of a Framework is stable in time but the business templates referring to a framework change according to amended reporting requirements in the course of time. A taxonomy represents a set of reporting requirements which are enforced by normative or legal acts for a period of time. The currency period starts with the entry into force of the law. In general a new taxonomy version replaces the previous one and the currency period of the old one ends before the new version becomes valid. A taxonomy consists Dictionary Elements that are valid for the currency period given by the taxonomy. Dictionary Elements which validTo date ended before the currency period start are not part of the taxonomy. Over the course of time several taxonomy versions exists which refer to one Framework.

In order to reduce the cost of maintenance, tables from previously released taxonomies that have not suffered any modification can be referred from a new taxonomy.

Framework

A framework consists of reporting regulations for a domain specific scope of information. The information requirements are structured in the form of tables to ease the understanding for the institutions that are obliged to submit the reporting information to the supervisor. All business rules to be met by the reporting entities are defined in the reporting regulations. Some of these rules are also incorporated in the table design to show which detailed information is being part of a summation.

A DPM can refer to one or more supervisory frameworks. Information should be given to which framework the defined elements of the DPM refer to.Comment-07

Superclass: Public Element

Taxonomy

A taxonomy, which is related to a framework Comment-08, is a specific view on a DPM for a specific period in time Comment-09. Its currency period is defined by the attributes validFrom and validTo. Only those dictionary elements are part of the taxonomy that are still valid for the defined period of time. Public elements like tables and hierarchies that have not been modified can be reused from the previous taxonomy version. Comment-10

Superclass: Public Element
XBRL equivalent: XBRL taxonomy

Table

The data requirements for supervisory purposes are described in guidelines or legal-normative standards. To ease the understanding of these regulatory texts supervisory experts provide business templates that show the data requirements in a convenient table structure. From a DPM perspective a template is just one possible representation of supervisory data in a specific business context. However, tables are used for the communication between supervisors and reporting entities so the DPM must contain presentational information to reconstruct the known tables on demand.

Comment-01
Superclass: Public Element

Dimension Validation Perspective

From a validation perspective taxonomy can be split in different modules that refer to a specific excerpt of a taxonomy. An excerpt might be linked to the information in one or more business templates being summarised under an specific aspect. In the reporting process a module defines a set of information that must be reported together. A Table Cubes represents sets of actual data requirements. It differs from a Table because it excludes those combinations of axes that are not required. Mostly those data is marked with gray cells inside the Business Templates. Each Data Point that corresponds to the data requirements of a reporting framework must have its representation in one of the Table Cubes of a Module.

Module

A Module consists of one or more tables which are combined the serve specific aspects in the reporting process. Modules define sets of business information that should be reported together, i.e. to conduct validation rules that are defined across tables.

Superclass: Public Element
XBRL equivalent: Entry point of an XBRL taxonomy

Table Cube

Some explanation.

Presentation Perspective

Data required by supervisors is described in legal normative acts and mostly reflected in bi-dimensional forms usually referred to as business templates. In most of the cases a business templates is represented by only one table. Sometimes such a convenient match is not possible because there is a high degree of complexity in the template that does not allow grouping the data points in the same view as the predefined template. A split of a business template in different tables is needed from a presentation perspective. A set of tables reflects then the data requirements defined in one business template. The DPM reflects the link between the business templates and the tables that represent their content.

A table consists of a combination of one or more axes. To each axis a set of Dictionary Elements is assigned to. The x-axis defines the columns as horizontal arrangement whereas the y-axis represents a vertical progression of rows in a table. The z-axis can be interpreted as the identifier of a sheet in a series of two-dimensional tables with the same structure. An axis can be also linked to one or more hierarchies build upon Dictionary Elements.

It is possible to assign Header Labels to an axis. They are specific to a table and only used for presentation purposes. One cell in a table is a combination of one column, one row and optional sheets and hires the dimensional combinations of the dictionary elements linked with these axes. A cell can represent a Data Point in the model if it corresponds to data requirements. In the case of the cell is not asked by a supervisor a dimensional validation ensures that the incorrect Data Point is being identified.

Hierarchy Perspective

Hierarchies in Data Point Models are defined to serve presentation and basic arithmetical purposes. A hierarchy is an arrangement of Dictionary Elements in tree structures. Two Dictionary Elements, one defines the parent and the second one the child element, build an hierarchical relationship of type presentation or rule.

Business rules are part of regulatory frameworks. They should ensure the quality of data being sent by the supervised entity. Rule Relationships have a sign attribute which identifies the arithmetical relationship between the two elements. Hierarchy relationships for presentation purposes need to define the order of the child element in the hierarchical network of the parent element.

Hierarchies are created for Enumerable Domains to show the relationships between Defined Members. It is also important to reflect an association between a Dimension and a hierarchy.

The meta model refers just to the hierarchies but not to the definiton of validation rules in a wider context. Validations rules can be defined by formulas in XBRL or implemented in any other programming language.

Hierarchy

Members as well as Dimensioned Elements can be arranged in hierarchies to represent the relationships to one another. In mathematical terms a hierarchy is a rooted tree that provides the information if a member is at top level, below another member or at the same level. Financial information is often split up in different segmental breakdowns which represent dimensions in multidimensional terms. If the members of a dimension share the same level of detail, they could be represented as a flat list. But often the members relate to each other, i.e. in a parent-child relationship, and so they form natural hierarchies. The information about the location of a member in a hierarchy of a dimension improves its understanding. Furthermore, hierarchies can be used to define rules for calculations or aggregations. In the DPM a hierarchy forms are sets of members of an explicit domain arranged in a hierarchical disposition.

Comment-02
Superclass: Public Element

Data Point Metamodel Constraints

General constraints

• 1.01   Each Public Element MUST have a code.
  For each Public Element a technical code MUST be defined.

context PublicElement inv: 
    self.code->size() = 1

• 1.02   Each Public Element MUST have at least one label.
  At least one label for a Public Element MUST be given which provides the human readable meaning of this element.

context PublicElement inv: 
    self.label->size() >= 1

• 1.03   All Public Elements belonging to a DPM MUST have unique codes.
  Using a code on more than one Public Element is not allowed.

context PublicElement inv: 
    self.allInstances()->isUnique(p : PublicElement | p.code)

• 1.04   All labels of the set of Public Elements MUST be unique.
  Creating more than one label refering to two different Public Elements is not allowed.

context PublicElement inv: 
    self.allInstances()->isUnique(p : PublicElement | p.label)

• 1.05   Each Dimensioned Element MUST define a data type and a period type.
  Each Dimensioned Element is to be determined by a data type and a period type.

context DimensionedElement inv: 
    self.dataType->size() = 1 
    and self.periodType->size() = 1

• 1.06   Each Defined Member must be referenced by an Enumerable Domain.
  Defined Members need a reference to an Enumerable Domain so that they are able to be used for the definition of data points.

context DataPointModel inv: 
    self.DefinedMember->forAll(m | m.EnumerableDomain->notEmpty())

• 1.07   Each Defined Member MUST be part of a hierarchy.
  In some cases breakdowns represent certain business notion rather than disagregation (e.g. Solo, IFRS consolidation, CRD consolidation). In such case the hierarchy would be just a flat list of members.
• 1.08   Each Enumerable Domain MUST have one default member.
  Some explanation.

context EnumerableDomain inv: 
    self.DefinedMember->select(isDefault = true)->size() = 1 

• 1.09   Each Enumerable Domain MUST refer to one or more hierarchies.
  Some explanation.
• 1.10   There MUST NOT be a doubling of members in different domains.
  Some explanation.
• 1.11   Each Dimension MUST point to one Domain.
  Some explanation.
• 1.12   Each hierarchy MUST have only one root member.
  The root of each hierarchy is an Enumerable Domain. The Defined Members should be attached underneath.
• 1.13   A member MUST be unique in a hierarchy.
  The same member must not be used twice in the same hierarchy.

XBRL specific constraints

• 2.01   Each Public Element MUST refer to the namespace of the owner.
  Each public element is defined by an institution or organization. The owner namespace is a URI used to establish the namespace of the Public elements defined by that owner.

Data warehouse specific constraints