Relationship

Relation: A relation is some interaction between the pieces which make up a financial report. A relation is a type of business rule. Components can be related to other components. Report components contain some facts, but not others. Facts can be related to other facts. Characteristics can be related to other characteristics. Facts are related to other facts mathematically. Members are related to other members. Concepts can be related to other concepts.

These different types of relationships are expressed in machine-readable form using XBRL arcroles. For example, see here. Also, see here. And, see here. Processing of the business rules could be proprietary to each software product (not optimal) or an agreed to global standard (optimal). Arcroles could be contributed to the XBRL International Link Role Registry (LRR).

General relations: The following is a summary of general types of relations:
  • Class-Equivalent Class: Both class extensions contain exactly the same set of individuals. Same as OWL definition of equivalentClass. For more information see http://www.w3.org/TR/owl-ref/#equivalentClass-def For example, if an economic entity creates an extension concept "my:CashAndCashEquivalents" and could indicate using this relation type that the extension concept created is an equivalent to "us-gaap:CashAndCashEquivalentsAtCost".
  • Class-subClass: (is-a) Indicates that something is a subclass of some other thing. Same as OWL definition of subclass. For more information see http://www.w3.org/TR/owl-ref/#subClassOf-def For example, if an economic entity creates an extension concept "my:PettyCash" and could indicate using this relation type that the extension concept created is a subclass or type of "us-gaap:CashAndCashEquivalents".
  • Full-hasPart: (whole-part) A has part B. Note that from A hasPart B we cannot infer that B is partOf A. Same as BFO definition of hasPart. For more information see http://genomebiology.com/2005/6/5/R46
  • Part-partOf: A is part of B. Note that from A partOf B we cannot infer that B hasPart A. Same as BFO definition of partOf. For more information see http://genomebiology.com/2005/6/5/R46
  • Entity-hasRole: A has part B. Note that from A hasPart B we cannot infer that B is partOf A. Same as BFO definition of hasPart. For more information see http://genomebiology.com/2005/6/5/R46
  • Class-Different from: The class is different from some other class.

Business report mechanical relations: The following are subclasses of concept arrangement patterns. (The US GAAP XBRL Taxonomy calls these [Line Items], the XBRL Dimensions specification calls these Primary Items):
  • Roll up: A roll up information model computes a total from a set of other concepts. The equation A + B + n = C articulates this model. All concepts involved in this information model have the same set of characteristics and all must be numeric.
  • Roll forward: A roll forward information model reconciles the balance of a concept between two points in time. This information model is commonly referred to a roll forward or movement analysis or by the equation: beginning balance + changes = ending balance. In this model the period [Axis] is as of two different points (instants) in time and the changes occur during the period (duration) between those two points in time.
  • Adjustment: An adjustment information model reconciles an originally stated balance to a restated balance, the adjustment being the total change, between two different report dates. An adjustment is similar to a roll forward in that it is a reconciliation, however rather than the period [Axis] changing; it is the Report Date [Axis] which changes: originally reported balance + adjustment = restated balance.
  • Variance: A variance information model reconciles some reporting scenario with another reporting scenario, the variance between reporting scenarios being the variance or changes. For example, a sales analysis which reconciles the concept sales for the reporting scenarios of actual and budgeted is a variance. The equation in this case is: actual - budget = variance. But a variance could take other forms such as a variance from forecast, variance from plan, etc.
  • Complex computation: A complex computation information model can be thought of as a hierarchy plus a set of commutations between different concepts within that hierarchy which are more challenging to represent than a roll up or roll forward. The type of computations can vary significantly, thus the challenging in modelling. For example, the computation of earnings per share, net income (loss) / weighted average shares = earnings per share, is a complex computation.
  • Hierarchy: A hierarchy information model denotes a set of concepts with no numeric relations between them. If no numeric relations exist, then the information model of the component is a hierarchy. Basically, anything can be represented as a hierarchy. It is the addition of additional relations, typically mathematical computations, which turns a hierarchy into some other concept arrangement pattern.
  • Text block: A text block information model is an information model which contains, by definition, exactly one concept and that concept expresses what amounts to a narrative or prose generally expressed as escaped HTML within that one concept. For example, the narrative associated with a set of accounting policies expressed as a list or a table presentation format is a text block. As there is only one concept, there can be no relations within the information model. (This MAY be a data type and NOT a concept arrangement pattern)

Whole-Part relations: The following are subclasses of whole-part type relations (for information see here and here on slide 9) (Cases specific to financial reporting need to be created, probably subclasses of these sorts of whole-part relations; most are likely member-collection types of relations)
  • Component-integralObject: Indicates that a component contains some integral object. For example, the component handle is part of the integral object cup; wheels are a component part of a car; a refrigerator is a component of a kitchen.
  • Member-collection: Indicates that some member is part of some collection. For example a ship is part of a fleet. Or, a subsidiary is part of an economic entity.
  • Portion-mass: Indicates that some portion is part of some mass. For example a slice is part of a pie.
  • Stuff-object: Indicates that some "stuff" is part of some object. For example steel is part of a car. (This may not be appropriate or necessary for financial reporting.)
  • Feature-activity: Indicates that some feature is part of some activity. For example the feature "paying" is part of the activity "shopping".
  • Place-area: Indicates that some physical place is part of some area. For example the place "Everglades" is part of the area "Florida".

Disclosure accounting relations: Other relations used to express business rules for a disclosure checklist include (in XBRL): (these are generally subclasses of other types of relations)
  • Financial report-requires disclosure: Indicates that a financial report (full) is always required to contain a specific disclosure (hasPart). This disclosure MUST always be present. For example, a financial report for a commercial and industrial company requires a balance sheet.
  • Disclosure-requires concept: Indicates that a disclosure (full) is required to contain a specific concept (hasPart). This concept MUST always be present for the specified disclosure. For example, a balance sheet requires the concept "Assets" and "Liabilities and Equity"
  • Disclosure-requires concept in context: Indicates that a disclosure is required to contain a specific concept and the context of the reported fact must be in the same context of some other reported fact. (This is not right) For example, if the concept "Current Assets" is provided, then the concept "Current liabilities" must also be provided in be in the same context.
  • Disclosure-requires characteristic: Indicates that the disclosure requires the specified characteristic (expressed as an Axis) to exist. For example, the "Segment Reporting Information, by Segment" disclosure requires the characteristic "Business segments" which is expressed using the Business Segment [Axis] of the US GAAP XBRL Taxonomy.
  • Disclosure-requires member: Indicates that the disclosure requires the specified Member to exist. (I am wondering if it should be the Characteristic which requires the Member or the disclosure requires the member?) For example, the "Business segments" characteristic requires the member "All business segments" to be provided which means that showing the total of all business segments is mandatory.
  • Disclosure-allows alternative disclosure: Indicates that an alternative disclosure can be used in place of another disclosure. For example, rather than providing an income statement and a statement of comprehensive income; a combined statement of income and comprehensive income could be provided.
  • Disclosure-requires disclosure: Indicated that if the first disclosure exits, the second disclosure must also exist. For example, if "the estimated useful life of property plant and equipment" exists, then the "depreciation method" must also exist.
  • Concept-allows alternative concept: Indicates that an alternative concept can be used in place of another concept. For example, the concept "Partner capital" or "Member equity" could be used and is an alternative for the concept "Equity". (Not sure if this is necessary, the class-equivalentClass might work.)
  • LineItems-requires concept: Indicates that the LineItems of a disclosure is required to contain a specified concept. (Not sure if this is necessary.) For example, the disclosure "Property, plant, and equipment, net by type [Roll Up]" requires the concept Property, Plant and Equipment, Net which is the total of the disclosure to exist.
  • Concept-requires policy: If a specific line item exists, then some specific disclosure exists.
  • Concept-requires disclosure: If a specific line item exists, then some specific disclosure must also exist.
  • Reported disclosure-requires disclosure: Indicates that if a specific disclosure exists, then some additional disclosure must also exist. For example, if the "Property, Plant, and Equipment, net by type " exists, then the disclosure "Property, plant, and equipment estimated useful lives" must also exist.
  • Disclosure-has concept arrangement pattern: Indicates that a disclosure is organized using the indicated concept arrangement pattern. For example, the disclosure "Property, plant, and equipment, net by type" is identified to be a "Roll Up" type concept arrangement pattern.
  • Reported fact-requires reported fact in context: Indicates that if a specified reported fact exist, then another reported fact is also required. For example, if the reported fact "Equity attributable to noncontrolling interest" is reported, then the concept "Equity attributable to parent" is required to be reported and must be in the same context. (Meaning that an economic entity cannot report equity attributable to noncontrolling interest without also reporting equity attributable to parent.
  • Reported fact-prohibits reported fact: Indicates that if some fact is reported, some other fact must never be reported. For example, if an economic entity reported the fact "us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease", then the reported fact "us-gaap:CashPeriodIncreaseDecrease" must not be reported. (This would make no sense because the two concepts both report "Net Cash Flow".)
  • Disclosure-equivalent text block: Indicates that if a specific disclosure exists, then a specific text block MUST also exist. For example, if the disclosure "Property, plant and equipment, net by type" exists as indicated by the existence of a specific reported fact "us-gaap:PropertyPlantAndEquipmentNet"; then a fact which reports the equivalent text block "us-gaap:PropertyPlantAndEquipmentTableTextBlock" MUST also exist.
  • Disclosure-has prior period comparison: Indicates that a disclosure provides prior period comparative information for the current disclosure. For example, for the "Property, plant and equipment, net by type" disclosure of the components which make up PPE, prior period information is provided.
  • Disclosure-related policy: Indicates that a disclosure has a specific policy which is related to the disclosure.
  • Concept-related policy: Indicates that a concept has a specific policy which is related to that concept.

Extensibility Rules Relations: Roles for articulating the extensibility of a report element in an XBRL taxonomy. (See this for understanding the need for these relations.)
  • Report Element-Required to Report: (covered by Reported fact-requires reported fact in context above) A reporting entity is required to report a report element. For example, all reporting entities are required to report "dei:EntityRegistrantName".
  • Report Element-Redefine or Replace Prohibited: A reporting entity is not allowed to create another report element which redefines or replaces the report element. For example, it makes no sense to redefine or replace the concept "dei:EntityRegistrantName" in the US GAAP XBRL Taxonomy.
  • Report Element-Insert Equivalent Class Allowed: Creating a new report element is not allowed (This seems equivalent to the rule just above)
  • Report Element-Insert Equivalent Class Prohibited: Creating a new report element which is an equivalent class of specified report element is prohibited. For example, a filer may NOT create an equivalent class for the concept "Entity registrant name".
  • Report Element-Insert Additional Children Allowed: A reporting entity is allowed to create one or more report elements which are a child to the report element. For example, a filer may create a child concept such as "Petty cash" for the concept "Cash and cash equivalents".
  • Report Element-Insert Additional Children Prohibited: A reporting entity is prohibited from creating child elements for a report element. For example, a filer is prohibited from creating a child concept for the concept "Assets". Filers MUST use ONLY the existing concepts "Current assets" and "Noncurrent assets".

Model structure relations: Model structure is a type of relation which describes how report elements relate to one another. Business rules are a type of relation which describes computation type and logic-based relations between reported facts. Flow is the relation between components. Information model is a type of relation between concepts which make up a subcomponent. Member aggregation model is the relation between the members which make up the domain of an axis.

Mathematical relations: How facts are related to other fact mathematically. These relations can be represented using XBRL Formula.