XBRL Abstract Model 1.0

Public Working Draft 19 October 2011

Copyright ©2011 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/abstractmodel-primary/PWD-2011-10-19/abstractmodel-primary-PWD-2011-10-19.html>
Editors:
Dave Frankel, SAP <dave.frankel@sap.com>
Raymond Lam, XBRL International Inc. <rayl@xbrl.org>
Warwick Foster, SBR Australia <warwick.foster@sbr.gov.au>
Contributors:
Herm Fischer, Mark V Systems <fischer@markv.com>
Hugh Wallis, Standard Dimensions <hugh@standarddimensions.com>
Jasdeep Singh Kaler, Infosys <jasdeepsk@infosys.com>
Marc Delbaere, Society for Worldwide Interbank Financial Telecommunication <Marc.DELBAERE@swift.com>
Masatomo Goto, Fujitsu <mg@jp.fujitsu.com>
Patrick Slattery, Canopach <xbrl@canopach.com>
Rob Nehmer, Oakland University <robnehmer@gmail.com>
Shweta Gupta, IRIS <shweta.gupta@irisbusiness.com>
Srinivas Murty, Ez-XBRL Solutions <srinivas.murty@ez-xbrl.com>
Walter Hamscher, U.S. Securities and Exchange Commission <walter@hamscher.com>
Yuta Tanaka, Fujitsu <tanaka.yuuta@jp.fujitsu.com>

Status

Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to modelling-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This document presents an abstract meta-model for the semantics that have been defined in the XBRL 2.1 [XBRL 2.1] and Dimensions 1.0 [DIMENSIONS] specifications.

Table of Contents

1 Overview
1.1 Charter
1.2 Scope
1.3 Model vs. meta-model
1.3.1 Domain modelling
1.4 Primary and secondary model
1.5 Relationship to other work
1.6 Language independence
2 Packaging
3 Extensible Element
3.1 Class ExtensibleElement
3.2 Class UserDefinedProperty
4 Fact Model
4.1 Class Entity
4.2 Class ExplicitAxisValue
4.3 Class Fact
4.4 Class FactCollection
4.5 Class FactProperty
4.6 Class FactStructuringRelationship
4.7 Class Footnote
4.8 Class ItemFact
4.9 Class Period
4.10 Class Scenario
4.11 Class Segment
4.12 Class StructuredFact
4.13 Class TypedAxisValue
5 Fact Typing
5.1 Class AbstractDecimalFact
5.2 Class DateOrDateTimeFact
5.3 Class FractionalNumericFact
5.4 Class MonetaryFact
5.5 Class NonFractionalNumericFact
5.6 Class NonNumericFact
5.7 Class NumericFact
5.8 Class PureNumericFact
5.9 Class SharesNumericFact
6 Concept Model
6.1 Axis
6.2 Class Calculation
6.3 Class Concept
6.4 Class ConceptContainer
6.5 Class Definition
6.6 Class ExplicitAxis
6.7 Class FilterableElement
6.8 Class FilterableRelationship
6.9 Class ItemConcept
6.10 Class ItemRelationship
6.11 Class Label
6.12 Class Member
6.13 Class ParentChildItemRelationship
6.14 Class Presentation
6.15 Class PrimaryItemRelationship
6.16 Class Reference
6.17 Class ReferencePart
6.18 Class Relationship
6.19 Class StructuredConcept
6.20 Class StructuringRelationship
6.21 Class Toggle
6.22 Class TypedAxis
7 Typing Model
8 Feedback requested

Appendices

A References
B Intellectual property status (non-normative)
C Acknowledgements (non-normative)
D Document history (non-normative)
E Errata corrections in this document


1 Overview

This document presents a meta-model for XBRL 2.1 [XBRL 2.1] and Dimensions 1.0 [DIMENSIONS] that separates the semantics defined in those specifications from their syntactical representation.

The meta-model will serve as a valuable technical resource that communicates the fundamental semantic value of these specifications.

1.1 Charter

The charter for the Abstract Modelling Task Force was defined by the XBRL Standards Board in these terms:

  • Scope: The abstract modelling task force will be responsible for delivering a UML model which captures the semantics of the XBRL 2.1 core specification and the Dimensions 1.0 specification. The UML model will capture the fundamental¬structures and design of XBRL and XBRL Dimensions as standalone UML artefacts, decoupled from any specific XML syntactical details.
  • Deliverables: The abstract model is likely to include use case diagrams, class diagrams, object diagrams, sequence diagrams and other such diagrams as may be later defined by the task force.
  • Audience: The abstract model will be developed with a specific focus towards software engineering, as a means of establishing a common framework for communicating and understanding the XBRL technology.

1.2 Scope

The Abstract Modelling Task Force recognises that there have been significant advancements made in a variety of other modules related to the core XBRL 2.1 and Dimensions 1.0 specifications. In particular, specifications such as Formulae, Rendering and Versioning have all added substantial features and capabilities on top of the two existing core specifications. However, the scope of the modelling effort was defined at the outset to be inclusive of only the XBRL 2.1 and Dimensions 1.0 specifications.

The Abstract Modelling Task Force has been respectful of this scope boundary, and has thus been careful to ensure that all constructs in the abstract model are traceable back to either the XBRL 2.1 or Dimensions 1.0 specifications.

1.3 Model vs. meta-model

To frame the efforts of the Abstract Modelling Task Force properly, it is important to understand the distinction between modelling and meta-modelling. Whereas a model is typically a representation of some phenomena in the real world, a meta-model is more concerned about describing and defining the actual modelling framework that is used to construct the model.

As an example, consider how common modelling frameworks such as SQL, XML and UML would contrast against each other at the meta-model level:

  • SQL would be defined in terms of tables, rows, columns, primary keys, foreign keys, etc.
  • XML would be defined in terms of elements, attributes, namespaces, etc.
  • UML would be defined in terms of classes, attributes, operations, associations, generalizations, etc.

Correspondingly, XBRL at the meta-model level would be defined in terms of concepts, facts, relationships, etc. The meta-model presented in this document describes XBRL in terms of the constructs that define it as a modelling framework.

1.3.1 Domain modelling

Once the traits of a meta-model are understood, IT professionals can then apply the meta-model to their task of modelling a specific domain. Meta-models are not responsible for expressing domain characteristics, but rather it is during the application of the meta-model to a given domain that domain-specific characteristics can be introduced into that specific instance of the meta-model.

Consequently, the meta-model presented in this document does not represent any specific taxonomy or domain project. However, it is anticipated that instances of this meta-model will eventually be created to communicate how XBRL has been applied in specific projects and taxonomies.

1.4 Primary and secondary model

A common issue that is addressed during modelling is that of scale, and identifying what level of abstraction or scale will be appropriate for the task at hand.

A fundamental principle which has guided the work of the Abstract Modelling Task Force has been to separate this issue of scale into 2 distinct layers of abstraction:

  1. the Primary Model - captures the pure semantics of XBRL and thus, as much as possible, is independent of the XML syntax
  2. the Secondary Model - captures the artefacts introduced by the XML syntax and is thus a more direct representation of the current specifications
Primary Secondary

The model presented in this document is the Primary Model, and is thus focused more on the semantics of XBRL than on the syntax. For this reason, the reader should be aware that certain artefacts of XBRL (such as Contexts, Arcs, and Locators) do not appear in this model as they have been considered to be artefacts of syntax rather than having any semantic significance.

1.5 Relationship to other work

This document pertains to XBRL as defined in the XBRL 2.1 Specification [XBRL 2.1].

This document pertains to XBRL Dimensions as defined in the Dimensions 1.0 Specification [DIMENSIONS].

1.6 Language independence

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

2 Packaging

The abstract model has been broken down into 3 packages, each of which builds upon the next:

  1. Fact Model - this package captures how XBRL facts can appear when they are instantiated. There is a sub package named Fact Types which further describes the hierarchy of fact types that are available. The Fact Model relies on the Concept Model to provide additional meta-information on Facts.
  2. Concept Model - this package captures how Concepts are defined along with the inter-Concept relationships, resources and axes. The Concept Model relies on the Typing Model to provide type information on the Concepts.
  3. Typing Model - this package captures the underlying types that have been defined by XBRL 2.1.
Packages

A color-coding scheme has been applied to the packages, and this scheme has been propagated throughout the classes in the class diagrams. To reinforce how the packages are related to each other there has been an effort made to ensure that at least one class from each of the packages appears in the relevant class diagrams.

3 Extensible Element

The ExtensibleElement is an abstract base class which models how various elements in XBRL are extensible through the ability to add custom XML attributes to those elements. This class diagram expresses which of the equivalent metaclasses in the model have that extensibility, and how that extensibility is provided through the UserDefinedProperty class.

Extensible Element

3.1 Class ExtensibleElement

Semantics

ExtensibleElement defines the ability that deriving metaclasses have for providing user extensibility. Users can extend deriving metaclasses by adding their own custom instances of UserDefinedProperty.

Rationale

The XML schemas for XBRL instance documents and linkbases allow for attributes from any namespace on certain elements. The ExtensibleElement metaclass and the UserDefinedProperty metaclass have been provided to capture those metaclasses in the model that need to reflect this extensibility, which has been defined by the underlying XBRL 2.1 specification.

Properties

ExtensibleElement is defined through related instances of UserDefinedProperty.

3.2 Class UserDefinedProperty

Semantics

The UserDefinedProperty enables users to add their own custom Properties to the set of Properties already occurring on an instance of the ExtensibleElement metaclass.

Rationale

The XML schemas for XBRL instance documents and linkbases allow for attributes from any namespace on certain elements. The UserDefinedProperty metaclass and the ExtensibleElement metaclass have been provided to capture those metaclasses in the model that need to reflect this extensibility, which has been defined by the underlying XBRL 2.1 specification.

Properties

Each occurrence of this metaclass has a name property and a value property. Occurrences of this metaclass belong to a single instance of ExtensibleElement, which is addressable through the extensibleElement property.

4 Fact Model

The Fact Model captures how XBRL data manifests itself when reported as business information.

The Fact is the core class of this model and has a direct association with a Concept, which provides additional meta-data about the Fact.

There are two types of Facts: a StructuringFact (i.e. an XBRL tuple) and an ItemFact. Subclasses of ItemFacts report actual values and these values can be further characterised through FactProperties. There are a minimum of two FactProperties - Entity and Period - and several other optional FactProperties including TypedAxisValue and ExplicitAxisValue.

Fact Model

4.1 Class Entity

Semantics

The Entity metaclass defines the entity (business, government department, individual, etc.) that an ItemFact describes.

Rationale

The Entity metaclass is a direct parallel to the entity element in the XBRL Instance Schema.

Properties

The Entity metaclass has two properties: identifier and scheme.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_4.7.3

4.2 Class ExplicitAxisValue

Semantics

The ExplicitAxisValue metaclass defines the instantiation of an explicit dimensional member, which further describes an ItemFact.

Rationale

The Dimensions 1.0 specification enables ItemFacts to be further described by specific values defined along zero-to-many dimensions or Axes. The ExplicitAxisValue metaclass is provided to capture explicit domain members, which may be associated with instances of an ItemFact.

Properties

The ExplicitAxisValue has a single property which is an explicit member along an ExplicitAxis.

4.3 Class Fact

Semantics

The Fact metaclass serves as the abstract base class for both ItemFacts and StructuredFacts. Facts are described by a corresponding Concept metaclass and are a specific instantiation of a Concept.

Rationale

The XBRL specification distinguishes between instance-based data and taxonomy-based data. Taxonomy-based data is defined through Concepts and instance-based data is defined through Facts. Facts and Concepts are tightly bound to one another, where a given Fact is a specific instantiation of a given Concept.

Properties

Facts are defined by a single Concept property named 'sourceConcept'. Facts can optionally have footnotes associated with them. Facts can be contained within zero or more FactCollections.

4.4 Class FactCollection

Semantics

The FactCollection metaclass represents a container that holds a flat list of Facts.

Rationale

The FactCollection provides a starting point for the set of Facts which are communicated, for example in an XBRL instance document. This metaclass is closely related to the xbrl element in the XBRL Instance Schema. A link to the definition of the XBRL element has been provided.

Properties

The Fact Collection can contain zero or many Facts.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_4.1

4.5 Class FactProperty

Semantics

FactProperty is an abstract base class for metaclasses that can define additional data characteristics about an ItemFact.

Rationale

For each ItemFact, XBRL stipulates that a minimum of 2 FactProperties be defined: an Entity and a Period. Additional FactProperties can be associated with an ItemFact including an optional Scenario, zero-to-many ExplicitAxisValues and zero-to-many TypedAxisValues.

4.6 Class FactStructuringRelationship

Semantics

The FactStructuringRelationship metaclass provides the means for a StructuredFact to express its parenting relationship(s) to other Facts.

Rationale

The XBRL specification provides a means for reporting a set of facts kept together through the tuple definition. The StructuredFact and FactStructuringRelationship metaclasses are intended to reflect this ability. The StructuredFact represents the instantiation of a tuple fact, whereas the FactStructuringRelationship represents the manner in which the StructuredFact is then related to other instantiations of Fact.

Properties

A FactStructuringRelationship is associated with one StructuredFact and with one-to-many Fact-derived classes. The property 'numberOfOccurrences' defines how many times a given Fact appears as a child of the StructuredFact.

4.7 Class Footnote

Semantics

Footnotes provide a means of associating additional commentary to a Fact.

Rationale

The XBRL specification defines Footnotes as a means of annotating Facts that occur in a FactCollection.

Properties

Footnotes have a single content property, which can be of any arbitrary type.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_4.11

4.8 Class ItemFact

Semantics

The ItemFact metaclass serves as the base class for Fact-derived classes that contain a value. Most of the Properties that are associated with item facts are provided at this level.

Rationale

The XBRL specification defines an item as a 'single fact or business measurement'. The hierarchy of classes that derive from ItemFact eventually leads to classes where a value of some type will be provided.

Properties

An ItemFact has a single Period, a single Entity, and an optional Scenario associated with it. An ItemFact can also have zero-to-many ExplitAxisValues / TypedAxisValues associated with it.

4.9 Class Period

Semantics

The Period metaclass defines the relevant time characteristics for an ItemFact. It can be a point in time, a duration, or 'forever'.

Rationale

Uses the natural concepts of stock (point) and flow (period).

Properties

Start date, end date.

4.10 Class Scenario

Semantics

The Scenario metaclass provides additional information about the status of an ItemFact.

Rationale

ItemFacts can exist in several possible worlds: budgeted, actual, etc. The Scenario metaclass provides metadata about which possible world is relevant for the ItemFact.

Properties

The Scenario metaclass has a single content property, which can be of any arbitrary type.

4.11 Class Segment

Semantics

The Segment metaclass defines the specific business unit of an Entity.

Rationale

The XBRL specification provides the segment element as a means of further identifying the business segment more completely, in cases where the entity identifier is insufficient or too broad.

Properties

The Segment metaclass has a single content property, which can be of any arbitrary type.

4.12 Class StructuredFact

Semantics

The StructuredFact metaclass represents facts which are parents of other Facts.

Rationale

The XBRL specification provides a means for reporting a set of facts kept together through the tuple definition. The StructuredFact and FactStructuringRelationship metaclasses reflect this ability. The StructuredFact represents the instantiation of a tuple fact, whereas the FactStructuringRelationship represents the manner in which the StructuredFact is then related to other instantiations of Fact.

Properties

The StructuredFact can be associated with zero-to-many FactStructuringRelationships.

4.13 Class TypedAxisValue

Semantics

The TypedAxisValue metaclass defines the instantiation of a typed dimensional member that further describes an ItemFact.

Rationale

The Dimensions 1.0 specification enables ItemFacts to be further described by specific values defined along zero-to-many dimensions or Axes. The TypedAxisValue metaclass is provided to capture a typed domain member that may be associated with instances of an ItemFact.

Properties

The TypedAxisValue has a single typedValue property. That property is a value that satisfies the type specification of a TypedAxis.

5 Fact Typing

The Fact Typing subpackage captures the library of fact types that are available as derived classes from ItemFact, and which of these add semantic significance to the meta-model. Only those that do add semantic significance have been explicitly documented below. NumericFacts have a unit property and NonFractionalNumericFacts have either a precision or decimals property.

Fact Typing

5.1 Class AbstractDecimalFact

Semantics

The AbstractDecimalFact allows for any decimal value to be reported.

Properties

It will have the value as a decimal and will inherit the fact properties from the ItemFact abstract class which will provide contextualisation. This will optionally allow for a decimal or precision attribute to be set against the value. It will also have a Unit value required, which will specify the measure applied to the value.

http://xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_5.1.1.3

5.2 Class DateOrDateTimeFact

Semantics

This is a metaclass which allows for a date or a dateTime to be stored for the value.

Rationale

This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a dateTimeItemType value. It has either a date or dateTime property.

Properties

The DateOrDateTimeFact metaclass has either a date property or a dateTime property, but not both.

Hyperlink

http://xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_5.1.1.3

5.3 Class FractionalNumericFact

Semantics

The FractionalNumericFact metaclass allows for a value to be specified in terms of a numerator and a denominator.

Rationale

This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a fractionItemType value.

Properties

The FractionalNumericFact has a numerator property and a denominator property. It also inherits the Unit property, which will specify the measure applied to the value.

5.4 Class MonetaryFact

Semantics

The monetaryItemType allows for any decimal value to be reported. The Unit of the metaclass is restricted to the ISO4217 currency list. The currency reported must also be valid at the time of reporting.

Rationale

This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a monetaryItemType value.

Properties

It will have the monetary value as a real number (decimal) and will inherit the fact properties from the ItemFact abstract class, which will provide contextualization. This will optionally allow for a decimal or precision attribute to be set against the value. It will also have a Unit value required, which will specify the measure applied to the value.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_4.8.2

5.5 Class NonFractionalNumericFact

Semantics

The NonFractionalNumericFact is an abstract metaclass that allows for the separation between the fraction class and non fractional classes.

Rationale

This class allows for either Decimals or Precision properties to be set again the nonfractional numeric value.

Properties

Unit will be required. Either Decimals or Precision can be applied to communicate accuracy.

5.6 Class NonNumericFact

Semantics

The NonNumericFact metaclass is an abstract base class that serves as the common root for facts which have non-numeric values.

The NonNumeric class is a abstract class that is used to separate Numeric and nonnumeric classes.

Rationale

The XBRL specification makes a distinction between numeric and non-numeric items.

NonNumeric has no additional characteristic.

Properties

None.

5.7 Class NumericFact

Semantics

The NumericFact metaclass is an abstract base class that serves as the common root for facts which specifically have a numeric value.

Numeric Fact is an abstract class that is used to separate the numeric and NonNumeric classes

Rationale

The XBRL specification makes a distinction between numeric and non-numeric items. Numeric items are distinguished from non-numeric items by the presence of a unit property.

Properties

NumericFacts have a unit property of type Unit.

The unit property has been modelled in this manner:

Units

5.8 Class PureNumericFact

Semantics

The pureItemType allows for any decimal value to be reported.

Rationale

This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a pureItemType value.

Properties

It will have the value as a real number (decimal) and will inherit the fact properties from the ItemFact abstract class, which will provide contextualization. This will optionally allow for a decimal or precision attribute to be set against the value. It will also have a Unit value required, which will specify the measure applied to the value.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_4.8.2

5.9 Class SharesNumericFact

Semantics

The timeItemType allows for either a Time value to be reported. The value of the Unit must be “Shares”

Rationale

This class is an Item data type defined by the XBRL standard v2.1 under section 5.1.1.3 and will hold a timeItemType value.

Properties

It will inherit the fact properties from the ItemFact abstract class, which will provide contextualization. This will optionally allow for a decimal or precision attribute to be set against the value. It will also have a Unit value required, which will specify the measure applied to the value.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_4.8.2

6 Concept Model

The Concept Model captures how elements can be defined for business reporting purposes.

The Concept is the core class of this model. There are two types of Concept: StructuredConcept (i.e. an XBRL tuple) and ItemConcept. The Relationship metaclass defines inter-Concept semantics such as Calculation and Presentation relationships.

FilterableElement and Toggle are abstractions of the prohibition and override capabilities that XBRL provides through relationship networks and base sets, and which are commonly leveraged through taxonomy extensions.

The ItemConcept to Axis association captures how the Dimensions 1.0 specification provides the ability to define Axes (e.g. dimensions) to further characterise how instances of a Concept might be realised.

Concept Model

6.1 Axis

Semantics

The Axis metaclass represents a dimension.

Rationale

The Dimensions specification provides the ability to define dimensions, which can be either typed or explicit. The Axis metaclass serves as the common abstract base class between the two.

Properties

The Axis metaclass has a name property which is of type QName.

Hyperlink

http://www.xbrl.org/Specification/XDT-REC-2006-09-18+Corrected-Errata-2009-09-07.htm#_Toc243301762

6.2 Class Calculation

Semantics

The Calculation metaclass is used to model aggregation of values from children to parents.

Rationale

Calculation is a specific type of parent/child relationship where the aggregation functionality is computable.

Properties

Weight as a weighting factor in the aggregation formula.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_Examples_42

6.3 Class Concept

Semantics

The Concept metaclass defines the business reporting elements that can occur in XBRL fact models.

Rationale

The XBRL specification defines two types of concepts: items and tuples. The Concept metaclass is the common abstract base class between the two of them.

Properties

The ItemConcept metaclass has a single name property.

6.4 Class ConceptContainer

Semantics

The ConceptContainer metaclass represents a container that holds a flat list of Concepts. ConceptContainers have the ability to export themselves and to import other ConceptContainers.

Rationale

The ConceptContainer provides a starting point for the set of Concepts and their Relationships that are typically communicated in XBRL taxonomies.

Properties

The ConceptContainer can contain zero or many Concepts.

6.5 Class Definition

Semantics

The Definition metaclass captures a variety of miscellaneous relationships between Concepts.

Rationale

The XBRL specification defines three specific types of relationships between concepts: presentation, calculation and definition.

Properties

None.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_Examples_43

6.6 Class ExplicitAxis

Semantics

The ExplicitAxis represents dimensions whose members are explicitly defined.

Rationale

The Dimensions specification makes a distinction between typed and explicit dimensions. The TypedAxis represents explicit dimensions.

Properties

The ExplicitAxis has zero-to-many members, which are the specific values permissible for the ExplicitAxis.

Hyperlink

http://www.xbrl.org/Specification/XDT-REC-2006-09-18+Corrected-Errata-2009-09-07.htm#_Toc243301765

6.7 Class FilterableElement

Semantics

The FilterableElement metaclass is an abstract base class from which derived classes inherit the ability to be toggled on or off.

Rationale

The XBRL specification defines a mechanism for prohibiting and overriding relationships. The FilterableElement defines a hierarchy of classes that participate in this mechanism.

Properties

The FilterableElement has an isEffective property, which is a derived property that determines whether a derived class has been toggled on or off. The role property is used to partition derived classes into networks of relationships and resources.

6.8 Class FilterableRelationship

Semantics

The FilterableRelationship is an abstract base class which derives from Relationship and FilterableElement. The combination of these two parent classes results in relationships which can be toggled on or off.

Rationale

The XBRL specification defines a mechanism for prohibiting and overriding relationships. The FilterableRelationship metaclass reflects this capability in XBRL.

Properties

None.

6.9 Class ItemConcept

Semantics

The ItemConcept metaclass defines specific elements that can be realized as facts in business reporting.

Rationale

The XBRL specification defines an item as a single fact or business measurement. ItemConcepts serve as the heart of the Concept Model.

Properties

ItemConcepts must be associated with a single ItemType. ItemConcepts can be on either the source or target end of Relationships. ItemConcepts can have zero or more Axes.

6.10 Class ItemRelationship

Semantics

The ItemRelationship metaclass is a specialisation of the Relationship metaclass and captures relationships specifically between ItemConcepts.

Rationale

The XBRL specification defines certain types of relationships that can exist only between ItemConcepts in particular, thereby excluding StructuredConcepts as possible sources or targets from the relationship.

Properties

None.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_5.2

6.11 Class Label

Semantics

The Label metaclass represents a human-readable name for Concepts.

Rationale

The XBRL specification defines labels as resources that can be defined to provide human-readable names and documentation for concepts.

Properties

The Label metaclass has a content property and a language property.

6.12 Class Member

Semantics

The Member metaclass defines a specific value along an ExplicitAxis.

Rationale

The Dimensions specification defines that an explicit dimension specifically names its members. The Member metaclass is used to represent those members.

Properties

The Member metaclass has a name property.

Hyperlink

http://www.xbrl.org/Specification/XDT-REC-2006-09-18+Corrected-Errata-2009-09-07.htm#_Toc243301742

6.13 Class ParentChildItemRelationship

Semantics

The ParentChildItemRelationship metaclass is a specialisation of the ItemRelationship metaclass where the source and target are effectively in a parent-child relationship.

Rationale

The XBRL specification defines relationships that can be interpreted as parent-child types of relationships.

Properties

None.

6.14 Class Presentation

Semantics

The Presentation metaclass captures presentational relationships between Concepts.

Rationale

The XBRL specification defines three specific types of relationships between concepts: presentation, calculation and definition.

Properties

The PresentationLink has a preferredLabel property.

Hyperlink

http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm#_Examples_44

6.15 Class PrimaryItemRelationship

Semantics

The PrimaryItemRelationship metaclass captures parent-child relationships where the parent plays the role of a primary item and the child plays the role of a descendant of that primary item.

Rationale

The Dimensions specification provides for inheritance of ItemConcept-to-Axis associations. The PrimaryItemRelationship metaclass captures this capability as defined by the Dimensions specification.

Properties

6.16 Class Reference

Semantics

The Reference metaclass represents pointers to the authoritative statements for Concepts.

Rationale

The XBRL specification defines references as resources that can be defined to point at authoritative material for concepts.

Properties

The Reference metaclass has zero-to-many ReferenceParts.

6.17 Class ReferencePart

Semantics

The ReferencePart metaclass represents the discrete parts that make up a Reference.

Rationale

The XBRL specification defines that references are composed of parts. The ReferencePart metaclass mirrors that capability.

Properties

The ReferencePart has a content property that can be of any type.

6.18 Class Relationship

Semantics

The Relationship metaclass is an abstract base class that defines a relationship between a single source Concept and a single target Concept.

Rationale

The XBRL specification defines specific kinds of relationships that can exist between concepts, or between a concept and a resource (such as a label or a reference). The Relationship metaclass serves as the common abstract base class for these specific kinds of relationships.

Properties

The Relationship metaclass has a source property and a target property.

6.19 Class StructuredConcept

Semantics

The StructuredConcept metaclass represents Concepts that are parents of other Concepts.

Rationale

The XBRL specification provides a means for defining structured groupings of concepts through the tuple definition. The StructuredConcept and StructuringRelationship metaclasses reflect this ability in XBRL.

Properties

None.

6.20 Class StructuringRelationship

Semantics

The StructuringRelationship metaclass is a type of Relationship that can be used to define structured groupings of Concepts.

Rationale

The XBRL specification provides a means for defining structured groupings of concepts through the tuple definition. The StructuredConcept and StructuringRelationship metaclasses reflect this ability in XBRL. The StructuringRelationship has a source property that is a StructuredConcept and a target property that is a Concept (and hence can be an ItemConcept or another StructuredConcept ).

Properties

The StructuringRelationship has a minOccurrences property, a maxOccurrences property, and a structuringKind property. These Properties are a reflection of the constraints commonly used in defining tuple content models.

6.21 Class Toggle

Semantics

The Toggle metaclass is applied to FilterableElements to toggle them on or off.

Rationale

The XBRL specification defines a mechanism for prohibiting and overriding elements. The FilterableElement and Toggle metaclasses reflect this capability in XBRL.

Properties

The Toggle metaclass has a priority property, which is used to resolve Toggle precedence in cases where there are multiple Toggles applied to a FilterableElement. The ToggleKind determines whether the Toggle action is to turn a FilterableElement on or off.

6.22 Class TypedAxis

Semantics

The TypedAxis metaclass represents dimensions whose members are based on an external type definition.

Rationale

The Dimensions specification makes a distinction between typed and explicit dimensions. The TypedAxis represents typed dimensions.

Properties

The TypedAxis has a type property, which is a URI that references an external type definition.

7 Typing Model

The Typing Model captures how XBRL provides a library of types from which taxonomy designers can derive their own custom types. The inventory of XBRL types has a large intersection with the built-in datatypes provided by XML Schema, but it's not an identical set - there are some types from XML Schema which XBRL does not use, and conversely there are several types which XBRL has added to the original XML Schema set.

The ItemType metaclass plays the central role in the Typing Model. The ItemType metaclass is directly associated with the ItemConcept metaclass from the Concept Model, and through that association provides the typing information to the Concept Model.

While there are some similarities in the class structures between the Typing Model and the Fact Types, there are important semantic differences that can be seen through the model. One significant difference is that the Typing Model does not have any provision for actual values, whereas many of the Fact Types provides that specific ability through a value property.

Typing Model

8 Feedback requested

The Abstract Modelling Task Force is seeking your input and opinions on these specific topics:

  1. Abstraction Level - A side effect of the abstraction process is that some of the detail and granularity defined at the raw specification level has been dissolved away into higher level abstractions. For instance, readers who are familiar with XBRL will notice that some well-known XBRL artefacts such as contexts, locators, and arcs are not present in the model. Others, like tuples, have been modelled in a manner that is more consistent with a model that intends to capture XBRL at the semantic level. The reader is invited to provide comments on the level of abstraction found in the model, and whether they feel that specific abstractions should be made more or less abstract.
  2. Fact-Concept Association - The Fact Model currently expresses the relationship between the Fact and Concept metaclasses as a direct association. The reader is invited to provide their opinion on whether this association should be modelled differently, quite possibly as a separate class that derives from FactProperty.
  3. Concept and Axes - The Concept Model currently expresses that Concepts can have a number of Axes associated with it. The Abstract Modelling Task Force recognises that this may be insufficient to capture the kind of sophisticated hypercube models which the Dimensions 1.0 specification currently allows. The reader is invited to comment on this portion of the Concept Model and to provide opinions on how they would like to see the Axis modelling enhanced.
  4. Tuple Abstractions - Tuples in XBRL have the ability to leverage XML Schema to define complex content models. In lieu of replicating an entire metamodel that represents XML Schema, the Concept Model has instead abstracted XBRL Tuples in terms of the StructuredConcept and StructuringRelationship metaclasses. The Abstract Modelling Task Force recognises that this may not have equivalent utility with XML Schema, so the reader is invited to comment on what capabilities of tuple content modelling they feel would be necessary to round out the existing capabilities of the Concept Model.
  5. Precision and Decimals - The reader is invited to comment on the use of precision and decimals in defining the degree of numerical accuracy as reported by non-fractional numeric facts. Are both required at the semantic level, or is it more preferable to reduce the two of them into a single abstraction? (For instance, see this document from the W3C on the precisionDecimal type.)

Feedback can sent to modelling-feedback@xbrl.org.

Appendix A References

DIMENSIONS
XBRL International Inc.. "XBRL Dimensions 1.0"
Ignacio Hernández-Ros
, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2008-07-02"
Phillip Engel
, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm)

Appendix B Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

Appendix C Acknowledgements (non-normative)

This document could not have been written without the contributions of many people.

Appendix D Document history (non-normative)

DateAuthorDetails
15 May 2011Raymond Lam

Initial document.

12 July 2011Hugh Wallis

Updates for (internal) publication as IWD.

10 October 2011Raymond Lam

Updates for publication as PWD

19 October 2011Hugh Wallis

Editorial for grammar, typos, UK/US spelling reconciliation and clarification of ambiguous wording.

Appendix E Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Abstract Modelling Task Force up to and including 19 October 2011. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.