From XBRLWiki

Revision as of 10:37, 14 January 2013 (edit) Katrin (Talk | contribs) (→Dimensioned Element) ← Previous diff		Revision as of 12:55, 14 January 2013 (edit) Katrin (Talk | contribs) (→Classes of the Data Point Metamodel) Next diff →
Line 89:		Line 89:
	===Dimension===		===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 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 unenumerable domain where the members are defined ba a data type and some additional contraints.
	'''Superclass''': ''Dictionary Element''<br/>		'''Superclass''': ''Dictionary Element''<br/>
	'''XBRL equivalent''': ''Abstract xbrli:item in the xbrldt:dimensionItem substitution group''		'''XBRL equivalent''': ''Abstract xbrli:item in the xbrldt:dimensionItem substitution group''
-
-	====Enumerable Dimension====
-	An enumerable dimension is a subclass of dimension that specifies a domain with a definite number of members.
-	<span style="background-color:yellow">RH: Is the dim-dom relationship 1:1 in DPM? I think the term enumerable and non-enumerable dimension is falsified. These terms belong to the domain. If there is a 1:1 between dim-dom that these terms are inherited from the domain. Still they don't have any impact on the dimension itself. I think what has been tried to express here is the XBRL typed and explicit dimension. But because DPM states the domain is mandatory, the characteristics regarding (non)enumerable move to the domain and do not stay in the dimension. From an UML perspective I would put the enumerable definition on the domain and have just one dimension class.</span>
-
-	'''Superclass''': ''Dimension''<br/>
-	'''XBRL equivalent''': ''Explicit dimension with dimension-domain arcs to zero or more domain member declarations.''
-
-	====Non-enumerable Dimension====
-	A non-enumerable dimension is a subclass of dimension that specifies a undefined number of members in the domain.
-
-	'''Superclass''': ''Dimension''<br/>
-	'''XBRL equivalent''': ''Typed dimension with a xbrldt:typedDomainRef attribute that defines the structured content of this dimension by an XML schema element.''
	===Domain===		===Domain===
Line 124:		Line 111:
	'''Superclass''': ''Domain''<br/>		'''Superclass''': ''Domain''<br/>
-	'''XBRL equivalent''': ''The set of members is defined by syntactic constraints on the contents of the xbrldt:typedDomainRef attribute.''	+	'''XBRL equivalent''': ''The set of members is defined by syntactic constraints on an XML schema element which is the content of the xbrldt:typedDomainRef attribute.''
	===Member===		===Member===

---

Revision as of 12:55, 14 January 2013

This page will be soon filled with actual content. For now the reader can consult some documents published by EBA [1]

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 Metamodel 6.1 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 Framework 6.1.5 Table 6.1.6 Hierarchy 6.1.7 Dimension 6.1.8 Domain 6.1.8.1 Enumerable Domain 6.1.8.2 Non-enumerable Domain 6.1.9 Member 6.1.9.1 Defined Member 6.1.9.2 Structural Member 6.1.10 Dimensioned Element 6.1.11 Element Set 6.1.11.1 Dimensioned Element Set 6.1.11.2 Member Set 6.1.11.3 Dimension Set 6.1.11.3.1 Family 6.1.11.3.2 Perspective

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 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 fullfilled 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 intend 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 Modell 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

There are currently no normative references.

Terms and definitions

There are no formal definitions that are taken from other documents.

Data Point Metamodel

The data point meta model provides (1) the model components for the creation of a formal models on sets of data points for 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 modeler. A UML class diagram is used to provide the syntax and semantic to define the metamodel for data points by showing the relevant classes and their attributes.

Classes of the Data Point Metamodel

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. As each public element is owned by an institution or 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

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.

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.

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.

Superclass: Public Element

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. RH: this does not take anything away for authors not providing a clear definition of each of the aspects that forms a single data point (or cell in a table).

Superclass: Public Element

Hierarchy

Elements can be arranged in hierarchies to represent the relationships to one another. In mathematical terms an hierarchy is a rooted tree that provides the information if a element is at top level, below another element 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 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. RH: The explanation is mixing elements with members. For DPM member hierarchies have more meaning than 'normal' element hierarchies may have.

Superclass: Public Element

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 unenumerable domain where the members are defined ba a data type and some additional contraints.

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

Domain

A classification system to categorize items that share a common semantic identity. A domain provides therefore a unambiquous 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
XBRL equivalent: A set of members instantiated by XML elements according to an XML schema definition (typed domain) or the QNames of these members (explicit domain).

Enumerable Domain

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

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

Non-enumerable Domain

A non-enumerable domain is a subclass of domain that specifies a undefined number of members in the domain. A specified pattern can be created to limit the values of the members in this domain.

Superclass: Domain
XBRL equivalent: The set of members is defined by syntactic constraints on an XML schema element which is the content of the 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 a certain semantic identity.

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

Defined Member

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.

Structural Member

Superclass: Member
XBRL equivalent: xbrldi:typedMember element which content is defined by 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 quantatively 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.

Element Set

A set consisting of dictionary elements. The set may consist of members that can be referenced by domains, a set of dimensioned elements or a set of dimensions which summarised dimensions in a specific business context.

Dimensioned Element Set

Superclass:Element Set

Member Set

Superclass:Element Set

Dimension Set

Superclass:Element Set

Family

Families are groups of dimensions only relevant for presentation purposes.

Superclass:Dimension Set

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.

Superclass:Dimension Set