From XBRLWiki

Revision as of 08:43, 22 February 2013 (edit) Hommes (Talk | contribs) (→Dictionary Element) ← Previous diff		Current revision (09:32, 17 May 2013) (edit) Hommes (Talk | contribs) (Added line when a table can be a single axis)
Line 3:		Line 3:
	'''Status''': Working Group Working Draft		'''Status''': Working Group Working Draft
		+	'''CEN WS XBRL Experts''': Thierry Declerck (DFKI), Roland Hommes (Rhocon), Katrin Heinze (Deutsche Bundesbank)
	'''Editing rules'''		'''Editing rules'''
Line 26:		Line 27:
	=Introduction=		=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 <span style="background-color:yellow">comment-03</span> 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.	+	Data Point Modelling is a data oriented methodical procedure to create semantic and multidimensional models that reflect the reporting requirements of European supervisors. Reporting requirements are defined by regulations and represented in tables. First Data Point Models (DPM) were developed in 2009 to describe the data in a redundancy-free, consistent and unambiguous way.
-	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.	+	Semantic models are used to ease the communication between domain experts and IT specialists. Whereas formal models are defined for technical purposes semantic models are defined from a viewpoint of a domain user. They can contain definitions, documentations and explanations. Domain experts decide which objects are relevant and which relations exists between the objects of the model. Semantic models are independent of any physical implementation.
		+
		+	The characteristic of multidimensional models is the division of data in quantitative and qualitative aspects. Parameters that are measured in figures (also known as metrics) are quantitative aspects that often build the basis of data analyses. Qualitative aspects provide a closer description for these parameters. Data objects based on multidimensional models are referred to as facts. Fact attributes are the quantitative aspects of a fact and dimensions are the synonym of the qualitative aspects of a fact.
		+
		+	A Data Point Model reflects semantic and multidimensional aspects of data modelling. Data Point Models should enhance the understanding of the data requirements for the reporting entities by providing information to correlations that exceed the information given only by table structures. The main challenge in data modelling is the identification of implicit information given in tables and its transformation in a logical model. Data Points Models are typically created by banking specialists who are highly skilled in understanding supervisory reporting frameworks.
		+
		+	This document intends to support the communication between supervisory experts and IT experts by introducing the concept of data point modelling and its underlying terms. Data Point Models remain as semantic models at first technologically-neutral but they are used by IT specialists (1) for generating data formats for the reporting process or (2) for designing multidimensional as well as relational database structures for the analysis of supervisory data.
	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.		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==		==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.	+	A Data Point Model consists of objects that reflect the supervisory metadata and their 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 definitions, rules and constraints 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==		==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.	+	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 on multidimensional models. 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==		==Relationship to Other Work==
Line 42:		Line 49:
	=Scope=		=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.	+	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. To reflect the defined structures in a machine-readable form they can be accompanied by an XBRL taxonomy. It is also possible to extend the described methodology to other environments.
	=Normative references=		=Normative references=
-	* [http://www.xbrl.org/specification/xbrl-recommendation-2003-12-31+corrected-errata-2012-01-25.htm XBRL 2.1]	+	<span style="background-color:#A9D0F5">Some text</span>
-	* [http://www.xbrl.org/specification/dimensions/rec-2012-01-25/dimensions-rec-2006-09-18+corrected-errata-2012-01-25-clean.html XBRL Dimensions 1.0]	+
	=Terms and definitions=		=Terms and definitions=
-	There are no formal definitions that are taken from other documents. <span style="background-color:yellow">comment-04</span>	+	There are no formal definitions that are taken from other documents.
-	=Data Point Meta model=	+	=Data Point Meta Model=
-	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,<span style="background-color:yellow">comment-05</span> (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.	+	The Data Point Meta Model provides (1) the components for the construction of a formal model that describes sets of [[European_Data_Point_Methodology#DataPoint|DataPoints]] relevant to European supervisory reporting frameworks, (2) definitions, rules and constraints 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.
-	[[Image:DpmMetaModel.jpg]]	+	==Structural Perspective==
-	==Meta classes of the Data Point Metamodel==	+	[[Image:StructuralPerspectiv.jpg]]
-	===Data Point Model===	+	===DataPointModel===
-	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.<br/>	+	A DataPointModel defines structures of data describing the characteristics of the information exchanged in the context of supervisory reporting processes. A DataPointModel consists of a dictionary of business concepts and their properties which are represented in tables. It identifies the content of each [[European_Data_Point_Methodology#DataPoint|DataPoint]] by its granular components with a semantic meaning and its relation to other data points. A DataPointModel has a mandatory attributue ''owner'' who needs to be made explicit.
-	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.	+	From an IT perspective a DataPointModel 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.
		+
		+	'''Contained elements''': ''[[European_Data_Point_Methodology#PublicElement|PublicElement]]''<br/>
-	<br/>
	'''References''':		'''References''':
	{| border="1" cellpadding="2" cellspacing="0"		{| border="1" cellpadding="2" cellspacing="0"
Line 70:		Line 77:
	! scope="col" width="650px" bgcolor="#E6E6E6" | description		! scope="col" width="650px" bgcolor="#E6E6E6" | description
	|-		|-
-	| Public Element || one or more || References the collection of Public Elements owned by a Data Point Model.	+	| PublicElement || one or more || References the collection of PublicElements owned by a DataPointModel.
	|}		|}
-	===Public Element===	+	===PublicElement===
-	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.	+	A PublicElement is a generalization of a concept of the model. It is identified by a code and consists of an appropriate label. PublicElements have two additional attributes giving information about the dates of creation and modification. Each PublicElement is owned by an institution or an organization. PublicElements are abstract and need to be specified by their concrete sub classes like [[European_Data_Point_Methodology#Framework|Frameworks]], [[European_Data_Point_Methodology#Table|Tables]] etc.
-	'''XBRL equivalent''': ''xbrli:item enhanced by the DPM specific XML attributes model:creationDate and model:modificationDate''<br/>
	'''References''':		'''References''':
	{| border="1" cellpadding="2" cellspacing="0"		{| border="1" cellpadding="2" cellspacing="0"
Line 83:		Line 89:
	! scope="col" width="650px" bgcolor="#E6E6E6" | description		! scope="col" width="650px" bgcolor="#E6E6E6" | description
	|-		|-
-	| Data Point Model || one or more || References the Data Point Model owning the collection of Public Elements.	+	| DataPointModel || exactly one || References the DataPointModel owning the collection of PublicElements.
	|}		|}
-	===Dictionary Element===	+	===DictionaryElement===
-	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.	+	DictionaryElement is an abstract class of elements that build the basis of the core concepts of a DataPointModel like [[European_Data_Point_Methodology#DimensionedElement|DimensionedElements]], [[European_Data_Point_Methodology#Dimension|Dimensions]], [[European_Data_Point_Methodology#Domain|Domains ]] and [[European_Data_Point_Methodology#DefinedMember|DefinedMembers]]. They are derived from PublicElements and may define a currency period to support versioning and 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 DataPointModel in the course of time.
	<span style="background-color:yellow">[[Talk:European_Data_Point_Methodology#Comment-06|Comment-06]]</span><br/>		<span style="background-color:yellow">[[Talk:European_Data_Point_Methodology#Comment-06|Comment-06]]</span><br/>
-	'''Superclass''': ''Public Element''<br/>	+	'''Superclass''': ''PublicElement''<br/>
-	'''XBRL equivalent''': ''xbrli:item based on the definition of the public element with two additional XML attributes model:fromDate and model:toDate.''	+
	===Framework===		===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 Framework is a business term common to a group of business users that consists of reporting regulations for a domain specific scope of information, like COREP, FINREP or Solvency II.
-	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.	+	The information requirements of a Framework are structured through business templates to ease the understanding for the reporting entities that are obliged to submit the information to their supervisor. A business template is a collection of supervisory data ordered in a representation that is fitting to the business domain. On basis of business templates users are able to understand the context and relationships between the required data. Business rules to be met by the reporting entities are also defined in the reporting regulations. Some rules are incorporated in the design of the business templates. E.g. the detailed information which is being part of a summation.
-	'''Superclass''': ''Public Element''	+	A DataPointModel can refer to one or more supervisory Frameworks. Information should be given to which Framework the defined elements of the DataPointModel refer to.
		+
		+	'''Superclass''': ''PublicElement''
	===Table===		===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.	+	A Table reflects the structure of a business template or represent an individual view on supervisory data based on a specific business context. As business templates are used for the communication between supervisors and reporting entities DataPoints are grouped in Tables in a DataPointModel to reconstruct the business templates for presentational purposes.
		+
		+	A DataPointModel thus must contain presentational information to reconstruct theses defined tables.
		+
		+	A Table consists of the combination of one, two or three [[European_Data_Point_Methodology#Axis|Axes]] which form [[European_Data_Point_Methodology#TableColumn|TableColumns]] (in the X-Axis), [[European_Data_Point_Methodology#TableRow|TableRows]] (in the Y-Axis) and [[European_Data_Point_Methodology#TableSheet|TableSheets]] (in the Z-Axis). A duplication of Tables is indicated by two or more TableSheets. Axes can be built on basis of a set of DictionaryElements that could be already defined in a Hierarchy. The combination of the DictionaryElements in each Axis defines a Cartesian product which represents the set of DataPoints reflected in a Table. Tables are normalized from a dimensional perspective and reflect the design constraint that a DictionaryElement can only be associated to one Axis.
		+
		+	'''Superclass''': ''PublicElement''
		+
		+	===TableGroup===
		+	A TableGroup is a set of Tables that represents a business template. A TableGroup is being created when a business template defines more than one table to reflect the business context. A TableGroup needs also to be created when the business template refers to the same dimension-member combinations in more than one axis. The business template is to be split in two or more Tables to prevent that the same Dimension is associated to a DataPoint more than once.
-	<span style="background-color:yellow">[[Talk:European_Data_Point_Methodology#Comment-01|Comment-01]]</span><br/>	+	'''Superclass''': ''PublicElement''
-	'''Superclass''': ''Public Element''	+
	===Hierarchy===		===Hierarchy===
-	Members 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 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.	+	[[European_Data_Point_Methodology#Member|Members]] as well as DimensionedElements 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 DataPointModel a Hierarchy forms are sets of DefinedMembers of an [[European_Data_Point_Methodology#EnumerableDimension|EnumerableDimension]] arranged in a hierarchical disposition.
-	<span style="background-color:yellow">[[Talk:European_Data_Point_Methodology#Comment-02|Comment-02]]</span><br/>	+	'''Superclass''': ''PublicElement''
-	'''Superclass''': ''Public Element''	+
	===Taxonomy===		===Taxonomy===
-	A taxonomy, which is related to a framework, is a specific view on a DPM for a specific period in time. 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 no been modified can be reused from the previous taxonomy version.	+	A Taxonomy combines the components for a version of the DataPointModel for a given period in time. Its currency period is defined by the attributes ''validFrom'' and ''validTo''.
		+	By creating a relation between Taxonomy and DictionaryElements, Tables and Hierarchies a set of valid DataPointModel components are being created.
		+	PublicElements like Table and Hierarchy can be reused when they have not been modified since the last Taxonomy version.
-	'''Superclass''': ''Public Element''<br/>	+	'''Superclass''': ''PublicElement''<br/>
-	'''XBRL equivalent''': ''XBRL taxonomy''	+
	===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.	+	A Module is a group of [[European_Data_Point_Methodology#DataCube|DataCubes]] that carry relevant identical semantics and may serve the reporting process. Modules define sets of business information that should be reported together, i.e. to conduct validation rules that are defined across DataCubes.
-	'''Superclass''': ''Public Element''<br/>	+	'''Superclass''': ''PublicElement''<br/>
-	'''XBRL equivalent''': ''Entry point of an XBRL taxonomy''	+
	===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 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.	+	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 DataPointModel Dimensions are used to group information in a meaningful way. Dimensions are used to define "by" conditions and provide structured information to describe a DataPoint in detail. A Dimension can refer to a Domain.
		+	Whereas the DimensionedElement represents the quantitative aspects, the qualitative aspects are described by Dimensions. The data elements given to Dimensions are called Members.
		+
		+	'''Superclass''': ''DictionaryElement''<br/>
-	'''Superclass''': ''Dictionary Element''<br/>
-	'''XBRL equivalent''': ''Abstract xbrli:item in the xbrldt:dimensionItem substitution group''<br/>
	'''References''':		'''References''':
	{| border="1" cellpadding="2" cellspacing="0"		{| border="1" cellpadding="2" cellspacing="0"
Line 136:		Line 151:
	! scope="col" width="650px" bgcolor="#E6E6E6" | description		! scope="col" width="650px" bgcolor="#E6E6E6" | description
	|-		|-
-	| Domain|| exactly one || References the Domain associated with a Dimension.	+	| Domain|| zero or more || References a collection of Domains associated with a Dimension.
		+	|-
		+	| Family|| zero or more || References the Families owning a collection of Dimensions.
	|}		|}
	===Domain===		===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.	+	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.	+	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 (syntax) pattern.
		+
		+	'''Contained elements''': ''Member''<br/>
-	'''Superclass''': ''Dictionary Element''<br/>
-	'''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).''<br/>
	'''References''':		'''References''':
	{| border="1" cellpadding="2" cellspacing="0"		{| border="1" cellpadding="2" cellspacing="0"
Line 151:		Line 168:
	! scope="col" width="650px" bgcolor="#E6E6E6" | description		! scope="col" width="650px" bgcolor="#E6E6E6" | description
	|-		|-
-	| Dimension || exactly one || References the Dimension associated with a Domain.	+	| Dimension || exactly one || References the Dimension associated with this Domain.
	|}		|}
-	====Enumerable Domain====	+	===EnumerableDimension===
-	An enumerable domain is a subclass of domain that specifies a definite number of members.	+	An EnumerableDimension is a subclass of Dimension that specifies a finite number of Members.
		+
		+	'''Superclass''': ''DictionaryElement, Dimension''<br/>
		+	'''Contained elements''': ''DefinedMember''<br/>
-	'''Superclass''': ''Domain''<br/>
-	'''Contained elements''': ''Member Set''<br/>
-	'''XBRL equivalent''': ''xbrli:items that form a discrete, countable and finite set of members to be referenced by explicit dimensions with dimension-domain arcs.''<br/>
	'''References''':		'''References''':
	{| border="1" cellpadding="2" cellspacing="0"		{| border="1" cellpadding="2" cellspacing="0"
Line 166:		Line 183:
	! scope="col" width="650px" bgcolor="#E6E6E6" | description		! scope="col" width="650px" bgcolor="#E6E6E6" | description
	|-		|-
-	| Member Set || exactly one || References the set of members owned by a Enumerable Domain.	+	| DefinedMember || one or more || References the set of DefinedMembers owned by an EnumerableDimension.
	|}		|}
-	====Non-enumerable Domain====	+	===NonEnumerableDimension===
-	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.	+	A NonEnumerableDimension is a subclass of Dimension that specifies an undefined number of Members in the Dimension. The NonEnumerableDimension defines syntactic constraints on the values of the Members, i.e. a dataType or a specific pattern.
-	'''Superclass''': ''Domain''<br/>	+	'''Superclass''': ''DictionaryElement, Dimension''<br/>
-	'''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.''	+	'''Contained elements''': ''NonDefinedMember''<br/>
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| NonDefinedMember|| one or more || References the set of NonDefinedMembers owned by an NonEnumerableDimension.
		+	|}
	===Member===		===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.	+	A Member is the data element that is given to a Dimension. Members can be grouped in Domains. Members in a Domain share certain semantic identity, just like the set of Members in a Dimension.
-	'''Superclass''': ''Dictionary element''<br/>	+	====DefinedMember====
-	'''XBRL equivalent''': ''Each one of the possibilities in the domain of a dimension.''	+	A DefinedMember is discrete and countable. These Members can be explicitly listed in an enumeration. The metaclass DefinedMember has an optional attribute ''default''.
-	====Defined Member====	+	'''Superclass''': ''DictionaryElement, Member''<br/>
-	A defined member is discrete and countable. A number of these members can be explicitly listed in an enumeration.	+
-	'''Superclass''': ''Member''<br/>	+	'''References''':
-	'''XBRL equivalent''': ''xbrldi:explicitMember which content is a QName of an xbrli:item referenced in a dimension-domain arc of an explicit dimension.''	+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| EnumerableDimension || exactly one || References the EnumerableDimension owning the collection of DefinedMembers.
		+	|}
-	====Non-defined Member====	+	====NonDefinedMember====
-	A non-defined member is defined by syntactic constraints on a possible value, not the value itself.	+	A NonDefinedMember is defined by syntactic constraints on a possible value, not the value itself.
	'''Superclass''': ''Member''<br/>		'''Superclass''': ''Member''<br/>
-	'''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===	+	'''References''':
-	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.	+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| NonEnumerableDimension || exactly one || References the NonEnumerableDimension owning the collection of NonDefinedMembers.
		+	|}
		+
		+	===DimensionedElement===
		+	DimensionedElements represent the nature of the data with a fixed and unchangeable meaning. DimensionedElements 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 DimensionedElement is the essential part of a DataPoint that can also refer to zero or more Dimensions with its according set of Members.
	<ul>		<ul>
	<li>The attribute dataType establishes the set of possible values of the facts reported according to that metric: monetary information, percentages, dates, texts…</li>		<li>The attribute dataType establishes the set of possible values of the facts reported according to that metric: monetary information, percentages, dates, texts…</li>
Line 200:		Line 239:
	</ul>		</ul>
-	'''Superclass''': ''Dictionary Element''<br/>	+	'''Superclass''': ''DictionaryElement''<br/>
-	'''XBRL equivalent''': ''xbrli:item in the sense of a primary item.''	+
-	====Dimension Set====	+	===Family===
-	This meta class is a set consisting of dimension elements, which summarizes dimensions in a specific business context.	+	Families are groups of Dimensions relevant for presentation or querying purposes.
		+	'''Superclass''': ''DictionaryElement''<br/>
	'''Contained elements''': ''Dimension''<br/>		'''Contained elements''': ''Dimension''<br/>
		+
	'''References''':		'''References''':
	{| border="1" cellpadding="2" cellspacing="0"		{| border="1" cellpadding="2" cellspacing="0"
Line 213:		Line 253:
	! scope="col" width="650px" bgcolor="#E6E6E6" | description		! scope="col" width="650px" bgcolor="#E6E6E6" | description
	|-		|-
-	| Data Point Model || zero or more || References the collection of Dimensions owned by a Data Point Model.	+	| Dimension|| zero or more || References the set of Dimensions owned by a Family.
	|}		|}
-	====Data Point====	+	==Versioning Perspective==
-	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.	+
		+	A DataPointModel 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 a law becoming effective. In general a new Taxonomy version must replace the previous one so the currency period of the old one ends before the new version becomes valid. It is not recommended to have two overlapping Taxonomy versions referring to the same reporting period.
-	=====Family=====	+	A Taxonomy consists of DictionaryElements that are valid for the currency period given by the Taxonomy. DictionaryElements 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 may 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 to from a new Taxonomy.
-	Families are groups of dimensions only relevant for presentation purposes.	+
-	'''Superclass''':''Dimension Set''	+	[[Image:VersioningPerspective.jpg]]
-	=====Perspective=====	+	'''DataPointModel'''
-	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''	+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Framework || one or more || References the collection of Frameworks owned by a DataPointModel.
		+	|}
-	==Perspectives of the Data Point Metamodel==	+	'''Framework'''
-	===Dimension Validation Perspective===	+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| DataPointModel || exactly one || References the DataPointModel owning a collection of Frameworks.
		+	|-
		+	| TableGroup || zero or more || References the set of TableGroups associated with this Framework.
		+	|-
		+	| Table || zero or more || References the set of Tables associated with this Framework.
		+	|}
		+
		+	'''Taxonomy'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| DictionaryElement || one or more || References the collection of valid DictionaryElements owned by a Taxonomy.
		+	|-
		+	| Table || zero or more || References the collection of Tables owned by a Taxonomy.
		+	|}
		+
		+	'''DictionaryElement'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Taxonomy|| exactly one || References the Taxonomy owning a collection of valid DictionaryElements.
		+	|}
		+
		+	'''Table'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Taxonomy|| exactly one || References the Taxonomy owning a collection of Tables.
		+	|-
		+	| Framework || exactly one || References the Framework associated with this Table.
		+	|-
		+	| TableGroup || exactly one || References the TableGroup owning a collection of Tables.
		+	|}
		+
		+	'''TableGroup'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Table || one or more || References the collection of Tables owned by a TableGroup.
		+	|-
		+	| Framework || exactly one || References the Framework associated with this TableGroup.
		+	|}
-	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.	+	==Dimension Validation Perspective==
		+	The dimensional validation that takes place on DataPoints is hosted by DataCubes. The dimensional validation is formed by a DimensionedElement combined with at least one Dimension that hosts at least one Member. Each DataPoint MUST be represented in one DataCube. From a dimensional validation perspective there can be no DimensionedElement that has no Dimensions. Eventhough this perspective shows that a DataPoint can only refer to a DimensionedElement without a relation to a Dimension. This is intentional because there is no rule that does not allow non-dimensional DataPoints.
	[[Image:DimensionPerspective.jpg]]		[[Image:DimensionPerspective.jpg]]
-	===Presentation Perspective===	+	===DataCube===
		+	A DataCube is a set of DataPoints with its appropriate Dimensions and Members. A DataCube must be part of at least one Module.
		+	A DataCube combines DataPoints that share the same dimensionality. The same dimensionality is given when the DataPoints have the same number of Dimensions and the Dimensions of each DataPoints are equivalent. In comparison to a Table a DataCube must not contain any combination of DictionaryElements that are not allowed. Non allowed data is often marked as gray cells in viewers on business templates.
-	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.	+	DataCubes may represent multiple business templates and vice versa, a single business template can be represented in multiple DataCubes, these groups may results in a Module.
-	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.	+	'''Contained elements''': ''DataPoint''<br/>
-	[[Image:PresentationPerspective.jpg]]	+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Module || exactly one || References the Module owning a set of DataCubes.
		+	|-
		+	| DataPoint|| zero or one || References the collection of DataPoints owned by a DataCube.
		+	|}
-	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.	+	===DataPoint===
		+	A DataPoint 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. A DataPoint can only have one DimensionedElement which holds the quantitative aspects about its dataType (e.g. text, number, percentage) and periodType (i.e. instant, duration). The qualitative aspects of a DataPoint is described by a (set of) Dimension(s) with each Dimension referring to at least one Member.
-	===Hierarchy Perspective===	+	An EnumerableDimension with a DefinedMember marked as default is implicitly applied when this Dimension is not explicitly associated to a DataPoint. Example: When the DataCube has a dimensional context of 10 Dimensions but only 8 Dimensions are associated with according Members to a DataPoint then two EnumerableDimensions are implicitly included with their default DefinedMembers.
-	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.	+	'''Contained elements''': ''Dimension'', ''DimensionedElement''<br/>
-	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.	+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| DimensionedElement || exactly one || References the element to be dimensioned by a set of Dimensions with their according Members.
		+	|-
		+	| Dimension || zero or more || References a set of Dimensions, each Dimension is linked to one Member.
		+	|}
-	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.	+	'''Taxonomy'''
		+
		+	'''Contained elements''': ''Module''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Module|| one or more || References the collection of Modules owned by a Taxonomy.
		+	|}
		+
		+	'''Module'''
		+
		+	'''Contained elements''': ''DataCube''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| DataCube|| zero or more || References the collection of DataCubes owned by a Module.
		+	|}
		+
		+	'''DimensionedElement'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| DataPoint|| zero or more || References the set of DataPoints owning the DimensionedElement.
		+	|}
		+
		+	'''Dimension'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| DataPoint|| zero or more || References the DataPoint owning a collection of Dimensions.
		+	|-
		+	| Member|| exactly one || References the Memeber associated with this Dimension.
		+	|}
		+
		+	'''Member'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Dimension|| zero or more || References the Dimension associated with this Member.
		+	|}
		+
		+	==Hierarchical Perspective==
		+
		+	Hierarchies are brought to the DataPointModel to serve different purposes and have three objectives:
		+	# Hierachies facilitate validation on DataPoints by defining logical and/or arithmetical relations between DictionaryElements (Eg. a total comprises of details).
		+	# Hierarchies provide information about how the DictionaryElements should be structured and visualised in a Table view.
		+	# Hierarchies increase the comprehensibility of DataPoints and their relation to each other. They ease also the maintenance of the DataPointModel.
		+
		+	Hierarchies are optional for DataPointModels. Nevertheless modelling experts advise to add each DefinedMember to a Hierarchy
		+
		+	For arithmetical relationships two warnings are in place:<br/>
		+	# When using multiple DimensionedElements on a single Dimension that has a Hierarchy in its DefinedMembers, the required math may not be possible to perform.
		+	# When using non-numeric typed DimensionedElements on a single Dimension that has a Hierarchy in its DefinedMembers, the required math may not be possible to perform.
	[[Image:BusinessrulePerspective.jpg]]		[[Image:BusinessrulePerspective.jpg]]
-	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.	+	===HierarchyRelationship===
		+	A HierarchyRelationship defines a logical relationship between a pair of DictionaryElements. One of these DictionaryElements defines the ''parent'' and the second defines the ''child''. Both DictionaryElements are referenced by their identifiers. A HierarchyRelationship can be of the type presentation, basic or rule and combines DictionaryElements of the same sub class.
-	===Versioning Perspective===	+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Hierarchy|| exactly one || References the hierarchy owning a collection of HierarchyRelationships.
		+	|-
		+	| Dictionary Element || two || References a pair of Dictionary elements of the same sub class.
		+	|}
-	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.	+	===RuleRelationship===
		+	A RuleRelationship is expressing a mathematical relationship between DimensionedElements.
		+	RuleRelationships have a sign attribute which identifies the arithmetical relationship between the two nested elements. The list of possible signs in a DataPointModel is not determined. Examples are: + (plus sign) or - (minus sign).
-	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.	+	'''Superclass''': ''HierarchyRelationship''
-	[[Image:VersioningPerspective.jpg]]	+	===PresentationRelationship===
		+	A PresentationRelationship is a Hierarchy for presentational purposes. The order attribute provides information about the ordering of childcodes within the same parentcode. All PresentationRelationships together form a tree structure to be visualized in (e.g.) an Axis of a Table.
		+
		+	'''Superclass''': ''HierarchyRelationship''
		+
		+	===BasicRelationship===
		+	A BasicRelationship is a Hierarchy for indicating semantic relationships that help forming the definition and therefore the comprehension of the structure that is present between DictionaryElements. This eases the maintenance of the DataPointModel.
		+
		+	'''Superclass''': ''HierarchyRelationship''
		+
		+	'''Hierarchy'''
		+
		+	'''Contained elements''': ''HierarchyRelationship''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Domain || exactly one || References the Domain owning the collection of Hierarchies.
		+	|-
		+	| Family|| exactly one|| References the Family owning a collection of Hierarchies.
		+	|-
		+	| Dimension || exactly one|| References the Dimension associated with a Hierarchy.
		+	|}
		+
		+	'''Dimension'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Hierarchy || zero or one || References the Hierarchy associated to this Dimension.
		+	|}
		+
		+	'''Domain'''
		+
		+	'''Contained elements''': ''Hierarchy''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Hierarchy || zero or more || References the collection of Hierarchies consisting of DefinedMembers owned by a Domain.
		+	|}
		+
		+	'''Family'''
		+
		+	'''Contained elements''': ''Hierarchy''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Hierarchy || zero or more || References the collection of Hierarchies consisting of Dimensions owned by a Family.
		+	|}
		+
		+	==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 template 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 DataPoints 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 DataPointModel 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. A single axis 'table' is represented as a flat list of concepts, no facts present. When facts need to be entered or presented a second axis is necessary. To each axis a set of DictionaryElements is assigned to. The X-axis defines the TableColumns as horizontal arrangement whereas the Y-axis represents a vertical progression of TableRows in a Table. The Z-axis can be interpreted as the identifier of a TableSheet in a series of two-dimensional Tables with the same structure. An Axis can be also linked to one or more Hierarchies build upon DictionaryElements.
		+
		+	[[Image:PresentationPerspective.jpg]]
		+
		+	It is possible to assign HeaderLabels to an Axis. They are specific to a Table and only used for presentation purposes. One TableCell in a Table is a combination of one TableColumn, one TableRow and optional TableSheets and inherits the dimensional combinations of the DictionaryElements linked with these axes. A TableCell can represent a DataPoint in the model if it corresponds to data requirements. In the case of the TableCell is not asked by a supervisor a dimensional validation ensures that the incorrect DataPoint is being identified.
		+
		+	===Axis===
		+	An Axis is considered the vertical or horizontal line that makes up the quadrants of a coordinate plane. The vertical Axis is usually referred to as the Y-axis and the horizontal Axis is usually referred to as the X-axis. In dimensional modelling the Z-axis is considered to represent anything that doesn't apply to the X- or Y-axis. In DataPointModel the Z-axis can best understood as the tabular sheets in a spreadsheet program, representing multiple slices of what the X- and Y-axis display. Often Z-axis content is presented as fixed parameters to the display of X and Y, usually represented in the graph header(s) and footer(s).
		+
		+	'''Contained elements''': ''HeaderLabel, DictionaryElement''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Hierarchy || one or more || References the Hierarchy associated with this Axis.
		+	|-
		+	| DictionaryElement || one or more || References the collection of DictionaryElements owned by an Axis.
		+	|-
		+	| HeaderLabel|| zero or more || References the collection of HeaderLabels owned by an Axis.
		+	|}
		+
		+	===TableRow===
		+	A TableRow is the representation of what the Y-axis is made up of: Each of the individual ordinates is represented on a single TableRow.
		+
		+	'''Superclass''': ''Axis''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| TableCell|| zero or one || References the TableCell associated with this TableRow.
		+	|}
		+
		+	===TableColumn===
		+	A TableColumn is the representation of what the X-axis is made up of: Each of the individual ordinates is represented on a single TableColumn.
		+
		+	'''Superclass''': ''Axis''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| TableCell|| zero or one || References the TableCell associated with this TableColumn.
		+	|}
		+
		+	===TableSheet===
		+	A TableSheet is the representation of what the Z-axis is made up of: Each of the individual ordinates CAN be represented on a single TableSheet.
		+
		+	'''Superclass''': ''Axis''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| TableCell|| zero or one || References the TableCell associated with this TableSheet.
		+	|}
		+
		+	===TableCell===
		+	A TableCell is the coordinate where the ordinates of X and Y axes meet. It represents a place where a single (fact) value can be shown or entered.
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| TableRow || zero or more || References the TableRow associated with this TableCell.
		+	|-
		+	| TableColumn || zero or more || References the TableColumn associated with this TableCell.
		+	|-
		+	| TableSheet || zero or more || References the TableSheet associated with this TableCell.
		+	|-
		+	| DataPoint || exactly one || References the DataPoint associated with this TableCell.
		+	|}
		+
		+	===HeaderLabel===
		+	A HeaderLabel is an additional label that is defined on an Axis to allow a grouping of different ordinates under a common headline.
		+
		+	'''Contained elements''': ''Axis''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Axis || exactly one || References the Axis owning a collection of HeaderLabels
		+	|}
		+
		+	'''Table'''
		+
		+	'''Contained elements''': ''Axis''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Axis || two or more || References the collection of Axis owned by a Table.
		+	|}
		+
		+	'''DictionaryElement'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Axis || exactly one || References the Axis owning a collection of DictionaryElements.
		+	|}
		+
		+	'''Hierarchy'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| Axis || zero or one || References the Axis associated with this Hierarchy.
		+	|}
		+
		+	'''DataPoint'''
		+
		+	'''References''':
		+	{| border="1" cellpadding="2" cellspacing="0"
		+	! scope="col" width="150px" bgcolor="#E6E6E6" | meta class
		+	! scope="col" width="100px" bgcolor="#E6E6E6" | multiplicity
		+	! scope="col" width="650px" bgcolor="#E6E6E6" | description
		+	|-
		+	| TableCell || exactly one || References the TableCell associated with this DataPoint.
		+	|}
	==Data Point Metamodel Constraints==		==Data Point Metamodel Constraints==
Line 274:		Line 698:
	<ul>		<ul>
	<li><span style="color:blue; font-weight:bold">1.01&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.01&nbsp;&nbsp;</span>
-	'''Each Public Element MUST have a code.'''	+	'''Each PublicElement MUST have a code.'''
	<br/>		<br/>
-	For each Public Element a technical code MUST be defined.	+	For each PublicElement a technical code MUST be defined.
	</li>		</li>
	'''context''' PublicElement '''inv''':		'''context''' PublicElement '''inv''':
	self.code->size() = 1		self.code->size() = 1
	<li><span style="color:blue; font-weight:bold">1.02&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.02&nbsp;&nbsp;</span>
-	'''Each Public Element MUST have at least one label.'''	+	'''All PublicElements belonging to a DataPointModel MUST have unique codes.'''
	<br/>		<br/>
-	At least one label for a Public Element MUST be given which provides the human readable meaning of this element.	+	Using a code on more than one PublicElement is not allowed.
	</li>		</li>
	'''context''' PublicElement '''inv''':		'''context''' PublicElement '''inv''':
-	self.label->size() >= 1	+	self.allInstances()->isUnique(p : PublicElement | p.code)
	<li><span style="color:blue; font-weight:bold">1.03&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.03&nbsp;&nbsp;</span>
-	'''All Public Elements belonging to a DPM MUST have unique codes.'''	+	'''Each PublicElement MUST have at least one label.'''
	<br/>		<br/>
-	Using a code on more than one Public Element is not allowed.	+	At least one Label for a PublicElement MUST be given which provides the human readable meaning of this element.
	</li>		</li>
	'''context''' PublicElement '''inv''':		'''context''' PublicElement '''inv''':
-	self.allInstances()->isUnique(p : PublicElement | p.code)	+	self.label->size() >= 1
	<li><span style="color:blue; font-weight:bold">1.04&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.04&nbsp;&nbsp;</span>
-	'''All labels of the set of Public Elements MUST be unique.'''	+	'''All labels of the set of PublicElements MUST be unique.'''
	<br/>		<br/>
-	Creating more than one label refering to two different Public Elements is not allowed.	+	Creating more than one label refering to two different PublicElements is not allowed.
	</li>		</li>
	'''context''' PublicElement '''inv''':		'''context''' PublicElement '''inv''':
	self.allInstances()->isUnique(p : PublicElement | p.label)		self.allInstances()->isUnique(p : PublicElement | p.label)
	<li><span style="color:blue; font-weight:bold">1.05&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.05&nbsp;&nbsp;</span>
-	'''Each Dimensioned Element MUST define a data type and a period type.'''	+	'''Each DimensionedElement MUST define a data type and a period type.'''
	<br/>		<br/>
-	Each Dimensioned Element is to be determined by a data type and a period type.	+	Each DimensionedElement is to be determined by a data type and a period type.
	</li>		</li>
	'''context''' DimensionedElement '''inv''':		'''context''' DimensionedElement '''inv''':
Line 310:		Line 734:
	'''and''' self.periodType->size() = 1		'''and''' self.periodType->size() = 1
	<li><span style="color:blue; font-weight:bold">1.06&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.06&nbsp;&nbsp;</span>
-	'''Each Defined Member must be referenced by an Enumerable Domain.'''	+	'''Each DefinedMember MUST be referenced by an EnumerableDimension.'''
	<br/>		<br/>
-	Defined Members need a reference to an Enumerable Domain so that they are able to be used for the definition of data points.	+	DefinedMembers need a reference to an EnumerableDimension so that they are able to be used for the definition of DataPoints.
	</li>		</li>
	'''context''' DataPointModel '''inv''':		'''context''' DataPointModel '''inv''':
-	self.DefinedMember->forAll(m | m.EnumerableDomain->notEmpty())	+	self.DefinedMember->forAll(m | m.EnumerableDimension->notEmpty())
	<li><span style="color:blue; font-weight:bold">1.07&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.07&nbsp;&nbsp;</span>
-	'''Each Defined Member MUST be part of a hierarchy.'''	+	'''Each DefinedMember SHOULD be part of a Hierarchy.'''
	<br/>		<br/>
-	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.	+	In some cases breakdowns represent certain business notion rather than disaggregation (e.g. Solo, IFRS consolidation, CRD consolidation). In such case the Hierarchy would be just a flat list of Members.
	</li>		</li>
	<li><span style="color:blue; font-weight:bold">1.08&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.08&nbsp;&nbsp;</span>
-	'''Each Enumerable Domain MUST have one default member.'''	+	'''A DefinedMember MUST be unique in a Hierarchy.'''
	<br/>		<br/>
-	<span style="background-color:#A9D0F5">Some explanation.</span>	+	The same Member MUST NOT be used twice in the same Hierarchy.
	</li>		</li>
-	'''context''' EnumerableDomain '''inv''':
-	self.DefinedMember->select(isDefault = true)->size() = 1
	<li><span style="color:blue; font-weight:bold">1.09&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.09&nbsp;&nbsp;</span>
-	'''Each Enumerable Domain MUST refer to one or more hierarchies.'''	+	'''There MUST NOT be a doubling of DefinedMembers in the same Dimension.'''
	<br/>		<br/>
-	<span style="background-color:#A9D0F5">Some explanation.</span>	+	A DefinedMember MUST only be references once in a Dimension.
	</li>		</li>
	<li><span style="color:blue; font-weight:bold">1.10&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.10&nbsp;&nbsp;</span>
-	'''There MUST NOT be a doubling of members in different domains.'''	+	'''Each Hierarchy MUST be build on basis of set of HierarchyRelationships of the same sub class.'''
	<br/>		<br/>
-	<span style="background-color:#A9D0F5">Some explanation.</span>	+	Hierarchies that serves a specific purpose should be defined by a set of common HierarchyRelationships. I.e. an aggregation should be based on a set of RuleRelationships.
	</li>		</li>
	<li><span style="color:blue; font-weight:bold">1.11&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.11&nbsp;&nbsp;</span>
-	'''Each Dimension MUST point to one Domain.'''	+	'''Each Hierarchy SHOULD give information about the Dimension that refer to it.'''
	<br/>		<br/>
-	<span style="background-color:#A9D0F5">Some explanation.</span>	+	It eases the identification of the correct hierarchy in a maintenance and impelementation process when a Hierarchy holds information about the Dimension that links to this hierarchy.
	</li>		</li>
	<li><span style="color:blue; font-weight:bold">1.12&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.12&nbsp;&nbsp;</span>
-	'''Each hierarchy MUST have only one root member.'''	+	'''Each DataPoint MUST be unique.'''
	<br/>		<br/>
-	The root of each hierarchy is an Enumerable Domain. The Defined Members should be attached underneath.	+	There MUST NOT be two data points with the same DimensionedElement, period and dimensional combinations.
	</li>		</li>
	<li><span style="color:blue; font-weight:bold">1.13&nbsp;&nbsp;</span>		<li><span style="color:blue; font-weight:bold">1.13&nbsp;&nbsp;</span>
-	'''A member MUST be unique in a hierarchy.'''	+	'''Valid DimensionedElements, DefinedMembers and Dimensions MUST be referenced by at least one DataPoint.'''
	<br/>		<br/>
-	The same member must not be used twice in the same hierarchy.	+	Valid DimensionedElements, DefinedMembers and Dimensions MUST be referenced by DataPoints defined in a Taxonomy with a matching currency period.
	</li>		</li>
	</ul>		</ul>
-	===XBRL specific constraints===	+	===Data warehouse specific constraints===
-		+
	<ul>		<ul>
-	<li><span style="color:blue; font-weight:bold">2.01&nbsp;&nbsp;</span>	+	<li><span style="color:blue; font-weight:bold">1.14&nbsp;&nbsp;</span>
-	'''Each Public Element MUST refer to the namespace of the owner.'''	+	'''Each EnumerableDimension MUST refer to at least one Hierarchy.'''
	<br/>		<br/>
-	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.	+	The DefinedMembers of an EnumerableDimension should be structured by parent-child relationships. In case a natural hierarchy cannot be derived a flat hierarchy should be created.
		+	</li>
		+	<li><span style="color:blue; font-weight:bold">1.15&nbsp;&nbsp;</span>
		+	'''Each Hierarchy MUST have only one root Member.'''
		+	<br/>
		+	In case a natural root in the collection of DefinedMembers can be derived, the DefinedMember set as default should be defined as the root.
		+	</li>
		+	<li><span style="color:blue; font-weight:bold">1.16&nbsp;&nbsp;</span>
		+	'''Hierarchies that represent aggregations by using RuleRelationships MUST NOT contain minus signs.'''
		+	<br/>
		+	In a data warehouse hierarchies are used to enable aggregations across members of dimensions. Minus signs in hierarchies prevent the usage of such a hierarchy in a data warehouse.
	</li>		</li>
	</ul>		</ul>
-	===Data warehouse specific constraints===	+	===European Taxonomy Architecture (ETA) specific constraints===
		+	<ul>
		+	<li><span style="color:blue; font-weight:bold">1.17&nbsp;&nbsp;</span>
		+	'''Each Member MUST be referenced by a Domain.'''
		+	<br/>
		+	Members need to be listed in Domains. Only Domains can be referenced by Dimensions.
		+	</li>
		+	'''context''' DataPointModel '''inv''':
		+	self.Member->forAll(m | m.Domain->notEmpty())
		+	<li><span style="color:blue; font-weight:bold">1.18&nbsp;&nbsp;</span>
		+	'''Each Domain SHOULD have one Member where the attribute ''default'' is set.'''
		+	<br/>
		+	For each EnumerableDimension that refers to this Domain the defined default for this Domain is applied. Together with rule 1.20 this rule ensures that each EnumerableDimension refers to a default which will be applied when the EnumerableDimension is not explicitly set for a DataPoint.
		+	</li>
		+	'''context''' Domain '''inv''':
		+	self.DefinedMember->select(isDefault = true)->size() = 1
		+	<li><span style="color:blue; font-weight:bold">1.19&nbsp;&nbsp;</span>
		+	'''Each Dimension MUST point to one Domain.'''
		+	<br/>
		+	A Dimension holds the information about the referenced Domain. A Dimension can only be linked with one Domain.
		+	</li>
		+	<li><span style="color:blue; font-weight:bold">1.20&nbsp;&nbsp;</span>
		+	'''There MUST NOT be a doubling of Members in different Domains.'''
		+	<br/>
		+	All DefinedMembers should be consistently defined. A DefinedMember holding a specific semantic meaning must not occur in different Domains.
		+	</li>
		+	</ul>

---

Current revision

CEN Workshop Agreement

Status: Working Group Working Draft

CEN WS XBRL Experts: Thierry Declerck (DFKI), Roland Hommes (Rhocon), Katrin Heinze (Deutsche Bundesbank)

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 Structural Perspective 6.1.1 DataPointModel 6.1.2 PublicElement 6.1.3 DictionaryElement 6.1.4 Framework 6.1.5 Table 6.1.6 TableGroup 6.1.7 Hierarchy 6.1.8 Taxonomy 6.1.9 Module 6.1.10 Dimension 6.1.11 Domain 6.1.12 EnumerableDimension 6.1.13 NonEnumerableDimension 6.1.14 Member 6.1.14.1 DefinedMember 6.1.14.2 NonDefinedMember 6.1.15 DimensionedElement 6.1.16 Family 6.2 Versioning Perspective 6.3 Dimension Validation Perspective 6.3.1 DataCube 6.3.2 DataPoint 6.4 Hierarchical Perspective 6.4.1 HierarchyRelationship 6.4.2 RuleRelationship 6.4.3 PresentationRelationship 6.4.4 BasicRelationship 6.5 Presentation Perspective 6.5.1 Axis 6.5.2 TableRow 6.5.3 TableColumn 6.5.4 TableSheet 6.5.5 TableCell 6.5.6 HeaderLabel 6.6 Data Point Metamodel Constraints 6.6.1 General constraints 6.6.2 Data warehouse specific constraints 6.6.3 European Taxonomy Architecture (ETA) specific constraints

Foreword

Some text

Introduction

Data Point Modelling is a data oriented methodical procedure to create semantic and multidimensional models that reflect the reporting requirements of European supervisors. Reporting requirements are defined by regulations and represented in tables. First Data Point Models (DPM) were developed in 2009 to describe the data in a redundancy-free, consistent and unambiguous way.

Semantic models are used to ease the communication between domain experts and IT specialists. Whereas formal models are defined for technical purposes semantic models are defined from a viewpoint of a domain user. They can contain definitions, documentations and explanations. Domain experts decide which objects are relevant and which relations exists between the objects of the model. Semantic models are independent of any physical implementation.

The characteristic of multidimensional models is the division of data in quantitative and qualitative aspects. Parameters that are measured in figures (also known as metrics) are quantitative aspects that often build the basis of data analyses. Qualitative aspects provide a closer description for these parameters. Data objects based on multidimensional models are referred to as facts. Fact attributes are the quantitative aspects of a fact and dimensions are the synonym of the qualitative aspects of a fact.

A Data Point Model reflects semantic and multidimensional aspects of data modelling. Data Point Models should enhance the understanding of the data requirements for the reporting entities by providing information to correlations that exceed the information given only by table structures. The main challenge in data modelling is the identification of implicit information given in tables and its transformation in a logical model. Data Points Models are typically created by banking specialists who are highly skilled in understanding supervisory reporting frameworks.

This document intends to support the communication between supervisory experts and IT experts by introducing the concept of data point modelling and its underlying terms. Data Point Models remain as semantic models at first technologically-neutral but they are used by IT specialists (1) for generating data formats for the reporting process or (2) for designing multidimensional as well as relational database structures for the analysis of supervisory data.

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 metadata and their 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 definitions, rules and constraints 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 on multidimensional models. 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. To reflect the defined structures in a machine-readable form they can be accompanied by an XBRL taxonomy. It is also possible to extend the described methodology to other environments.

Normative references

Some text

Terms and definitions

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

Data Point Meta Model

The Data Point Meta Model provides (1) the components for the construction of a formal model that describes sets of DataPoints relevant to European supervisory reporting frameworks, (2) definitions, rules and constraints 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.

Structural Perspective

DataPointModel

A DataPointModel defines structures of data describing the characteristics of the information exchanged in the context of supervisory reporting processes. A DataPointModel consists of a dictionary of business concepts and their properties which are represented in tables. It identifies the content of each DataPoint by its granular components with a semantic meaning and its relation to other data points. A DataPointModel has a mandatory attributue owner who needs to be made explicit.

From an IT perspective a DataPointModel 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.

Contained elements: PublicElement

References:

meta class	multiplicity	description
PublicElement	one or more	References the collection of PublicElements owned by a DataPointModel.

PublicElement

A PublicElement is a generalization of a concept of the model. It is identified by a code and consists of an appropriate label. PublicElements have two additional attributes giving information about the dates of creation and modification. Each PublicElement is owned by an institution or an organization. PublicElements are abstract and need to be specified by their concrete sub classes like Frameworks, Tables etc.

References:

meta class	multiplicity	description
DataPointModel	exactly one	References the DataPointModel owning the collection of PublicElements.

DictionaryElement

DictionaryElement is an abstract class of elements that build the basis of the core concepts of a DataPointModel like DimensionedElements, Dimensions, Domains and DefinedMembers. They are derived from PublicElements and may define a currency period to support versioning and 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 DataPointModel in the course of time.

Comment-06

Superclass: PublicElement

Framework

A Framework is a business term common to a group of business users that consists of reporting regulations for a domain specific scope of information, like COREP, FINREP or Solvency II.

The information requirements of a Framework are structured through business templates to ease the understanding for the reporting entities that are obliged to submit the information to their supervisor. A business template is a collection of supervisory data ordered in a representation that is fitting to the business domain. On basis of business templates users are able to understand the context and relationships between the required data. Business rules to be met by the reporting entities are also defined in the reporting regulations. Some rules are incorporated in the design of the business templates. E.g. the detailed information which is being part of a summation.

A DataPointModel can refer to one or more supervisory Frameworks. Information should be given to which Framework the defined elements of the DataPointModel refer to.

Superclass: PublicElement

Table

A Table reflects the structure of a business template or represent an individual view on supervisory data based on a specific business context. As business templates are used for the communication between supervisors and reporting entities DataPoints are grouped in Tables in a DataPointModel to reconstruct the business templates for presentational purposes.

A DataPointModel thus must contain presentational information to reconstruct theses defined tables.

A Table consists of the combination of one, two or three Axes which form TableColumns (in the X-Axis), TableRows (in the Y-Axis) and TableSheets (in the Z-Axis). A duplication of Tables is indicated by two or more TableSheets. Axes can be built on basis of a set of DictionaryElements that could be already defined in a Hierarchy. The combination of the DictionaryElements in each Axis defines a Cartesian product which represents the set of DataPoints reflected in a Table. Tables are normalized from a dimensional perspective and reflect the design constraint that a DictionaryElement can only be associated to one Axis.

Superclass: PublicElement

TableGroup

A TableGroup is a set of Tables that represents a business template. A TableGroup is being created when a business template defines more than one table to reflect the business context. A TableGroup needs also to be created when the business template refers to the same dimension-member combinations in more than one axis. The business template is to be split in two or more Tables to prevent that the same Dimension is associated to a DataPoint more than once.

Superclass: PublicElement

Hierarchy

Members as well as DimensionedElements 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 DataPointModel a Hierarchy forms are sets of DefinedMembers of an EnumerableDimension arranged in a hierarchical disposition.

Superclass: PublicElement

Taxonomy

A Taxonomy combines the components for a version of the DataPointModel for a given period in time. Its currency period is defined by the attributes validFrom and validTo. By creating a relation between Taxonomy and DictionaryElements, Tables and Hierarchies a set of valid DataPointModel components are being created. PublicElements like Table and Hierarchy can be reused when they have not been modified since the last Taxonomy version.

Superclass: PublicElement

Module

A Module is a group of DataCubes that carry relevant identical semantics and may serve the reporting process. Modules define sets of business information that should be reported together, i.e. to conduct validation rules that are defined across DataCubes.

Superclass: PublicElement

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 DataPointModel Dimensions are used to group information in a meaningful way. Dimensions are used to define "by" conditions and provide structured information to describe a DataPoint in detail. A Dimension can refer to a Domain. Whereas the DimensionedElement represents the quantitative aspects, the qualitative aspects are described by Dimensions. The data elements given to Dimensions are called Members.

Superclass: DictionaryElement

References:

meta class	multiplicity	description
Domain	zero or more	References a collection of Domains associated with a Dimension.
Family	zero or more	References the Families owning a collection of Dimensions.

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 (syntax) pattern.

Contained elements: Member

References:

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

EnumerableDimension

An EnumerableDimension is a subclass of Dimension that specifies a finite number of Members.

Superclass: DictionaryElement, Dimension
Contained elements: DefinedMember

References:

meta class	multiplicity	description
DefinedMember	one or more	References the set of DefinedMembers owned by an EnumerableDimension.

NonEnumerableDimension

A NonEnumerableDimension is a subclass of Dimension that specifies an undefined number of Members in the Dimension. The NonEnumerableDimension defines syntactic constraints on the values of the Members, i.e. a dataType or a specific pattern.

Superclass: DictionaryElement, Dimension
Contained elements: NonDefinedMember

References:

meta class	multiplicity	description
NonDefinedMember	one or more	References the set of NonDefinedMembers owned by an NonEnumerableDimension.

Member

A Member is the data element that is given to a Dimension. Members can be grouped in Domains. Members in a Domain share certain semantic identity, just like the set of Members in a Dimension.

DefinedMember

A DefinedMember is discrete and countable. These Members can be explicitly listed in an enumeration. The metaclass DefinedMember has an optional attribute default.

Superclass: DictionaryElement, Member

References:

meta class	multiplicity	description
EnumerableDimension	exactly one	References the EnumerableDimension owning the collection of DefinedMembers.

NonDefinedMember

A NonDefinedMember is defined by syntactic constraints on a possible value, not the value itself.

Superclass: Member

References:

meta class	multiplicity	description
NonEnumerableDimension	exactly one	References the NonEnumerableDimension owning the collection of NonDefinedMembers.

DimensionedElement

DimensionedElements represent the nature of the data with a fixed and unchangeable meaning. DimensionedElements 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 DimensionedElement is the essential part of a DataPoint 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: DictionaryElement

Family

Families are groups of Dimensions relevant for presentation or querying purposes.

Superclass: DictionaryElement
Contained elements: Dimension

References:

meta class	multiplicity	description
Dimension	zero or more	References the set of Dimensions owned by a Family.

Versioning Perspective

A DataPointModel 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 a law becoming effective. In general a new Taxonomy version must replace the previous one so the currency period of the old one ends before the new version becomes valid. It is not recommended to have two overlapping Taxonomy versions referring to the same reporting period.

A Taxonomy consists of DictionaryElements that are valid for the currency period given by the Taxonomy. DictionaryElements 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 may 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 to from a new Taxonomy.

DataPointModel

References:

meta class	multiplicity	description
Framework	one or more	References the collection of Frameworks owned by a DataPointModel.

Framework

References:

meta class	multiplicity	description
DataPointModel	exactly one	References the DataPointModel owning a collection of Frameworks.
TableGroup	zero or more	References the set of TableGroups associated with this Framework.
Table	zero or more	References the set of Tables associated with this Framework.

Taxonomy

References:

meta class	multiplicity	description
DictionaryElement	one or more	References the collection of valid DictionaryElements owned by a Taxonomy.
Table	zero or more	References the collection of Tables owned by a Taxonomy.

DictionaryElement

References:

meta class	multiplicity	description
Taxonomy	exactly one	References the Taxonomy owning a collection of valid DictionaryElements.

Table

References:

meta class	multiplicity	description
Taxonomy	exactly one	References the Taxonomy owning a collection of Tables.
Framework	exactly one	References the Framework associated with this Table.
TableGroup	exactly one	References the TableGroup owning a collection of Tables.

TableGroup

References:

meta class	multiplicity	description
Table	one or more	References the collection of Tables owned by a TableGroup.
Framework	exactly one	References the Framework associated with this TableGroup.

Dimension Validation Perspective

The dimensional validation that takes place on DataPoints is hosted by DataCubes. The dimensional validation is formed by a DimensionedElement combined with at least one Dimension that hosts at least one Member. Each DataPoint MUST be represented in one DataCube. From a dimensional validation perspective there can be no DimensionedElement that has no Dimensions. Eventhough this perspective shows that a DataPoint can only refer to a DimensionedElement without a relation to a Dimension. This is intentional because there is no rule that does not allow non-dimensional DataPoints.

DataCube

A DataCube is a set of DataPoints with its appropriate Dimensions and Members. A DataCube must be part of at least one Module. A DataCube combines DataPoints that share the same dimensionality. The same dimensionality is given when the DataPoints have the same number of Dimensions and the Dimensions of each DataPoints are equivalent. In comparison to a Table a DataCube must not contain any combination of DictionaryElements that are not allowed. Non allowed data is often marked as gray cells in viewers on business templates.

DataCubes may represent multiple business templates and vice versa, a single business template can be represented in multiple DataCubes, these groups may results in a Module.

Contained elements: DataPoint

References:

meta class	multiplicity	description
Module	exactly one	References the Module owning a set of DataCubes.
DataPoint	zero or one	References the collection of DataPoints owned by a DataCube.

DataPoint

A DataPoint 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. A DataPoint can only have one DimensionedElement which holds the quantitative aspects about its dataType (e.g. text, number, percentage) and periodType (i.e. instant, duration). The qualitative aspects of a DataPoint is described by a (set of) Dimension(s) with each Dimension referring to at least one Member.

An EnumerableDimension with a DefinedMember marked as default is implicitly applied when this Dimension is not explicitly associated to a DataPoint. Example: When the DataCube has a dimensional context of 10 Dimensions but only 8 Dimensions are associated with according Members to a DataPoint then two EnumerableDimensions are implicitly included with their default DefinedMembers.

Contained elements: Dimension, DimensionedElement

References:

meta class	multiplicity	description
DimensionedElement	exactly one	References the element to be dimensioned by a set of Dimensions with their according Members.
Dimension	zero or more	References a set of Dimensions, each Dimension is linked to one Member.

Taxonomy

Contained elements: Module

References:

meta class	multiplicity	description
Module	one or more	References the collection of Modules owned by a Taxonomy.

Module

Contained elements: DataCube

References:

meta class	multiplicity	description
DataCube	zero or more	References the collection of DataCubes owned by a Module.

DimensionedElement

References:

meta class	multiplicity	description
DataPoint	zero or more	References the set of DataPoints owning the DimensionedElement.

Dimension

References:

meta class	multiplicity	description
DataPoint	zero or more	References the DataPoint owning a collection of Dimensions.
Member	exactly one	References the Memeber associated with this Dimension.

Member

References:

meta class	multiplicity	description
Dimension	zero or more	References the Dimension associated with this Member.

Hierarchical Perspective

Hierarchies are brought to the DataPointModel to serve different purposes and have three objectives:

1. Hierachies facilitate validation on DataPoints by defining logical and/or arithmetical relations between DictionaryElements (Eg. a total comprises of details).
2. Hierarchies provide information about how the DictionaryElements should be structured and visualised in a Table view.
3. Hierarchies increase the comprehensibility of DataPoints and their relation to each other. They ease also the maintenance of the DataPointModel.

Hierarchies are optional for DataPointModels. Nevertheless modelling experts advise to add each DefinedMember to a Hierarchy

For arithmetical relationships two warnings are in place:

1. When using multiple DimensionedElements on a single Dimension that has a Hierarchy in its DefinedMembers, the required math may not be possible to perform.
2. When using non-numeric typed DimensionedElements on a single Dimension that has a Hierarchy in its DefinedMembers, the required math may not be possible to perform.

HierarchyRelationship

A HierarchyRelationship defines a logical relationship between a pair of DictionaryElements. One of these DictionaryElements defines the parent and the second defines the child. Both DictionaryElements are referenced by their identifiers. A HierarchyRelationship can be of the type presentation, basic or rule and combines DictionaryElements of the same sub class.

References:

meta class	multiplicity	description
Hierarchy	exactly one	References the hierarchy owning a collection of HierarchyRelationships.
Dictionary Element	two	References a pair of Dictionary elements of the same sub class.

RuleRelationship

A RuleRelationship is expressing a mathematical relationship between DimensionedElements. RuleRelationships have a sign attribute which identifies the arithmetical relationship between the two nested elements. The list of possible signs in a DataPointModel is not determined. Examples are: + (plus sign) or - (minus sign).

Superclass: HierarchyRelationship

PresentationRelationship

A PresentationRelationship is a Hierarchy for presentational purposes. The order attribute provides information about the ordering of childcodes within the same parentcode. All PresentationRelationships together form a tree structure to be visualized in (e.g.) an Axis of a Table.

Superclass: HierarchyRelationship

BasicRelationship

A BasicRelationship is a Hierarchy for indicating semantic relationships that help forming the definition and therefore the comprehension of the structure that is present between DictionaryElements. This eases the maintenance of the DataPointModel.

Superclass: HierarchyRelationship

Hierarchy

Contained elements: HierarchyRelationship

References:

meta class	multiplicity	description
Domain	exactly one	References the Domain owning the collection of Hierarchies.
Family	exactly one	References the Family owning a collection of Hierarchies.
Dimension	exactly one	References the Dimension associated with a Hierarchy.

Dimension

References:

meta class	multiplicity	description
Hierarchy	zero or one	References the Hierarchy associated to this Dimension.

Domain

Contained elements: Hierarchy

References:

meta class	multiplicity	description
Hierarchy	zero or more	References the collection of Hierarchies consisting of DefinedMembers owned by a Domain.

Family

Contained elements: Hierarchy

References:

meta class	multiplicity	description
Hierarchy	zero or more	References the collection of Hierarchies consisting of Dimensions owned by a Family.

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 template 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 DataPoints 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 DataPointModel 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. A single axis 'table' is represented as a flat list of concepts, no facts present. When facts need to be entered or presented a second axis is necessary. To each axis a set of DictionaryElements is assigned to. The X-axis defines the TableColumns as horizontal arrangement whereas the Y-axis represents a vertical progression of TableRows in a Table. The Z-axis can be interpreted as the identifier of a TableSheet in a series of two-dimensional Tables with the same structure. An Axis can be also linked to one or more Hierarchies build upon DictionaryElements.

It is possible to assign HeaderLabels to an Axis. They are specific to a Table and only used for presentation purposes. One TableCell in a Table is a combination of one TableColumn, one TableRow and optional TableSheets and inherits the dimensional combinations of the DictionaryElements linked with these axes. A TableCell can represent a DataPoint in the model if it corresponds to data requirements. In the case of the TableCell is not asked by a supervisor a dimensional validation ensures that the incorrect DataPoint is being identified.

Axis

An Axis is considered the vertical or horizontal line that makes up the quadrants of a coordinate plane. The vertical Axis is usually referred to as the Y-axis and the horizontal Axis is usually referred to as the X-axis. In dimensional modelling the Z-axis is considered to represent anything that doesn't apply to the X- or Y-axis. In DataPointModel the Z-axis can best understood as the tabular sheets in a spreadsheet program, representing multiple slices of what the X- and Y-axis display. Often Z-axis content is presented as fixed parameters to the display of X and Y, usually represented in the graph header(s) and footer(s).

Contained elements: HeaderLabel, DictionaryElement

References:

meta class	multiplicity	description
Hierarchy	one or more	References the Hierarchy associated with this Axis.
DictionaryElement	one or more	References the collection of DictionaryElements owned by an Axis.
HeaderLabel	zero or more	References the collection of HeaderLabels owned by an Axis.

TableRow

A TableRow is the representation of what the Y-axis is made up of: Each of the individual ordinates is represented on a single TableRow.

Superclass: Axis

References:

meta class	multiplicity	description
TableCell	zero or one	References the TableCell associated with this TableRow.

TableColumn

A TableColumn is the representation of what the X-axis is made up of: Each of the individual ordinates is represented on a single TableColumn.

Superclass: Axis

References:

meta class	multiplicity	description
TableCell	zero or one	References the TableCell associated with this TableColumn.

TableSheet

A TableSheet is the representation of what the Z-axis is made up of: Each of the individual ordinates CAN be represented on a single TableSheet.

Superclass: Axis

References:

meta class	multiplicity	description
TableCell	zero or one	References the TableCell associated with this TableSheet.

TableCell

A TableCell is the coordinate where the ordinates of X and Y axes meet. It represents a place where a single (fact) value can be shown or entered.

References:

meta class	multiplicity	description
TableRow	zero or more	References the TableRow associated with this TableCell.
TableColumn	zero or more	References the TableColumn associated with this TableCell.
TableSheet	zero or more	References the TableSheet associated with this TableCell.
DataPoint	exactly one	References the DataPoint associated with this TableCell.

HeaderLabel

A HeaderLabel is an additional label that is defined on an Axis to allow a grouping of different ordinates under a common headline.

Contained elements: Axis

References:

meta class	multiplicity	description
Axis	exactly one	References the Axis owning a collection of HeaderLabels

Table

Contained elements: Axis

References:

meta class	multiplicity	description
Axis	two or more	References the collection of Axis owned by a Table.

DictionaryElement

References:

meta class	multiplicity	description
Axis	exactly one	References the Axis owning a collection of DictionaryElements.

Hierarchy

References:

meta class	multiplicity	description
Axis	zero or one	References the Axis associated with this Hierarchy.

DataPoint

References:

meta class	multiplicity	description
TableCell	exactly one	References the TableCell associated with this DataPoint.

Data Point Metamodel Constraints

General constraints

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

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

• 1.02   All PublicElements belonging to a DataPointModel MUST have unique codes.
  Using a code on more than one PublicElement is not allowed.

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

• 1.03   Each PublicElement MUST have at least one label.
  At least one Label for a PublicElement MUST be given which provides the human readable meaning of this element.

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

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

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

• 1.05   Each DimensionedElement MUST define a data type and a period type.
  Each DimensionedElement 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 DefinedMember MUST be referenced by an EnumerableDimension.
  DefinedMembers need a reference to an EnumerableDimension so that they are able to be used for the definition of DataPoints.

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

• 1.07   Each DefinedMember SHOULD be part of a Hierarchy.
  In some cases breakdowns represent certain business notion rather than disaggregation (e.g. Solo, IFRS consolidation, CRD consolidation). In such case the Hierarchy would be just a flat list of Members.
• 1.08   A DefinedMember MUST be unique in a Hierarchy.
  The same Member MUST NOT be used twice in the same Hierarchy.
• 1.09   There MUST NOT be a doubling of DefinedMembers in the same Dimension.
  A DefinedMember MUST only be references once in a Dimension.
• 1.10   Each Hierarchy MUST be build on basis of set of HierarchyRelationships of the same sub class.
  Hierarchies that serves a specific purpose should be defined by a set of common HierarchyRelationships. I.e. an aggregation should be based on a set of RuleRelationships.
• 1.11   Each Hierarchy SHOULD give information about the Dimension that refer to it.
  It eases the identification of the correct hierarchy in a maintenance and impelementation process when a Hierarchy holds information about the Dimension that links to this hierarchy.
• 1.12   Each DataPoint MUST be unique.
  There MUST NOT be two data points with the same DimensionedElement, period and dimensional combinations.
• 1.13   Valid DimensionedElements, DefinedMembers and Dimensions MUST be referenced by at least one DataPoint.
  Valid DimensionedElements, DefinedMembers and Dimensions MUST be referenced by DataPoints defined in a Taxonomy with a matching currency period.

Data warehouse specific constraints

• 1.14   Each EnumerableDimension MUST refer to at least one Hierarchy.
  The DefinedMembers of an EnumerableDimension should be structured by parent-child relationships. In case a natural hierarchy cannot be derived a flat hierarchy should be created.
• 1.15   Each Hierarchy MUST have only one root Member.
  In case a natural root in the collection of DefinedMembers can be derived, the DefinedMember set as default should be defined as the root.
• 1.16   Hierarchies that represent aggregations by using RuleRelationships MUST NOT contain minus signs.
  In a data warehouse hierarchies are used to enable aggregations across members of dimensions. Minus signs in hierarchies prevent the usage of such a hierarchy in a data warehouse.

European Taxonomy Architecture (ETA) specific constraints

• 1.17   Each Member MUST be referenced by a Domain.
  Members need to be listed in Domains. Only Domains can be referenced by Dimensions.

context DataPointModel inv: 
    self.Member->forAll(m | m.Domain->notEmpty())

• 1.18   Each Domain SHOULD have one Member where the attribute default is set.
  For each EnumerableDimension that refers to this Domain the defined default for this Domain is applied. Together with rule 1.20 this rule ensures that each EnumerableDimension refers to a default which will be applied when the EnumerableDimension is not explicitly set for a DataPoint.

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

• 1.19   Each Dimension MUST point to one Domain.
  A Dimension holds the information about the referenced Domain. A Dimension can only be linked with one Domain.
• 1.20   There MUST NOT be a doubling of Members in different Domains.
  All DefinedMembers should be consistently defined. A DefinedMember holding a specific semantic meaning must not occur in different Domains.