Reconciling Seattle Method, OIM, SBRM, XBRL

The purpose of this blog post is to reconcile the alignment of the Seattle Method, XBRL International's Open Information Model (OIM), and the Object Management Group's Standard Business Report Model (SBRM).  The Seattle Method, OIM, and SBRM are pretty much aligned because the Seattle Method is based on XBRL and OIM and the Seattle Method is also the basis for much of SBRM.

The Seattle Method, OIM, and SBRM will then form an aligned formal global industry standards based conceptualization of  a business report and the foundation upon which model-driven digital business reporting (including financial reporting) ecosystem will be built.

First off, the Seattle Method, OIM, and SBRM should be grounded in some sort of upper level or top level ontology. This provides a rock solid foundation. Second, the objective is to create something like an "accounting oracle", metadata for an ecosystem. That is the bigger picture.

The following are a handful of key "things" in the Seattle Method, OIM, XBRL, and SBRM that tend to be undisputed. These things might not be formally or consistently described; but that is the objective. These are the "keystones" or "cornerstones", the high level artifacts upon which more detail will be built.  This may seem like a simple system, but as Gall's Law points out, "A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work."

Note that SBRM provides a UML model for these artifacts, the Seattle Method provides an informal visualization, XBRL provides an abstract model (public draft, not recommendation) for these artifacts:

  • Fact (a.k.a. Item, Primary Item, Line Item)
    • Per Seattle Method, "A fact is reported. A fact defines a single, observable, reportable piece of information contained within a business report, or fact value, contextualized for unambiguous interpretation or analysis by one or more distinguishing aspects (properties of the fact). A fact value is one property of a fact. Every fact has exactly one fact value.
    • Per OIM, "A fact is a discrete piece of information in an XBRL Report. All facts have the following properties."
    • Per XBRL, "Facts can be simple, in which case their values must be expressed as simple content (except in the case of simple facts whose values are expressed as a ratio), and facts can be compound, in which case their value is made up from other simple and/or compound facts. Simple facts are expressed using items (and are referred to as items in this specification) and compound facts are expressed using tuples (and are referred to as tuples in this specification)."
    • Per SBRM (page 4), "A single data point, including metadata, for a concept in a report, equivalent to a cell in a spreadsheet, including its value. Often the fact value takes the form of a number, but it can also be textual information, or narrative/prose.) UML
  • Report (a.k.a. business report)
    • Per Seattle Method, "Information published by a reporting entity at some point in time for some purpose. For example a financial report is a type of report. A report can be broken down into information fragments."
    • Per OIM, "A set of facts."
    • Per XBRL, "XBRL instances are XML fragments with root element, <xbrl> . XBRL instances contain business report facts, with each fact corresponding to a Concept defined in their supporting DTS. XBRL instances also contain contexts and units that provide additional information needed to interpret the facts in the instance."
    • Per SBRM (page 5), "A structured file or document created or generated by an organization for intended delivery to one or more other organizations, typically a regulator. UML
  • Entity (a.k.a. Reporting Entity Aspect, Entity Core Dimension)
    • Per Seattle Method, "A reporting entity aspect is a core aspect that distinguishes the economic entity which creates a report."
    • Per OIM, "The entity core dimension represents the primary legal entity (person or organisation) associated with a fact."
    • Per XBRL, "A business entity, the subject of XBRL items."
    • Per SBRM (page 4), "The organization which is the subject of a report." UML
  • Report Element (a.k.a. model element)
    • Per Seattle Method, "A report element is an element within the model definition of an information block." NOTE types of report elements include network, hypercube, dimension, member, line items, abstract, and concept.
    • Per OIM, undefined. NOTE that the "concept code dimension" is equivalent to the report element type of "concept" which is a specialization of report element.
    • Per XBRL, "Concepts are defined in two equivalent ways. In a syntactic sense, a concept is an XML Schema element definition, defining the element to be in the item element substitution group or in the tuple element substitution group. At a semantic level, a concept is a definition of a kind of fact that can be reported about the activities or nature of a business activity." NOTE, the term "concept" as used by XBRL and the term "report element" are equivalent. In the Seattle Method, SBRM, and  OIM the term "concept" is a type of (specialization) of a report element.
    • Per SBRM (page 20), "The most general entity in the hierarchy represents any element that can appear in a report. It is also referred to as an Item. Report Elements can take various forms, depending on their role in the definition of the report." UML
  • Dimension (a.k.a. Aspect, Axis)
    • Per Seattle Method, "A dimension is a type of report element. a.k.a. aspect or Axis. An aspect describes a fact (an aspect is a property of a fact). An aspect or distinguishing aspect provides information necessary to describe a fact or distinguish one fact from another fact within a report. A fact may have only the three core aspects (entity, calendar period, concept) or zero to many additional noncore distinguishing aspects."
    • Per OIM, "A dimension is a piece of additional information that serves to uniquely identify a fact. A dimension may either be one of the core dimensions listed below or a taxonomy-defined dimension."
    • Per XBRL via XBRL Dimensions, "Each of the different aspects by which a fact MAY be characterised." NOTE see also Technical Considerations for the use of XBRL Dimensions 1.0; 
    • Per SBRM (page 4), "A characteristic of a fact in addition to its value such as unit of measure, time or geographical scope; they can be used to organize or present a collection of facts in different ways." UML
  • Member
    • Per Seattle Method, "A member is a type of report element."
    • Per OIM, undefined or implied to be defined by XBRL Dimensions.  NOTE should say that member is defined per XBRL Dimensions.
    • Per XBRL via XBRL Dimensions, "Each one of the possibilities in the domain of a Dimension. Explicit domains are defined by domain-member relations. Example: In the "Products Dimension" an explicit domain can be created with each one of the products as a domain-member. Domain member items are in the substitution group of xbrli:item."
    • Per SBRM (pages 21 and 26),  "Represents an individual element within a Dimension, covered in more detail in 7.8.  A Member represents an individual element within a Member Arrangement Pattern." UML
  • Line Items (a.k.a. Primary Items, Item)
    • Per Seattle Method, "A line items is a type of report element."
    • Per OIM, the closest thing is concept core dimension but this is not precise because line items can also contain abstract report elements.
    • Per XBRL, "An item is an element in the substitution group for the XBRL item element. It contains the value of the simple fact and a reference to the context (and unit for numeric items) needed to correctly interpret that fact. When items occur as children of a tuple, they must also be interpreted in light of the other items and tuples that are children of the same tuple. There are numeric items and non-numeric items, with numeric items being required to document their measurement accuracy and units of measurement." NOTE XBRL Dimensions defines the term Primary Item as being an XBRL item.
  • Hypercube (a.k.a. Cube, Table)
    • Per Seattle Method, "A hypercube is a type of report element. A.k.a. table or cube."
    • Per OIM, Same as XBRL Dimensions.
    • Per XBRL via XBRL Dimensions, "A hypercube represents a set of dimensions. Hypercubes are abstract elements in the substitution group of hypercubeItem that participate in has-hypercube relations and hypercube-dimension relations."
    • Per SBRM (page 4) "A multi-dimensional data structure used to represent complex financial information. It allows the data to be analyzed and viewed from multiple perspectives simultaneously, enabling more dynamic and detailed reporting. Hypercubes are particularly useful for handling large datasets with various dimensions, such as time, geographic location, product lines, and financial metrics."  UML
  • Information Block (a.k.a. Block, Fact Set)
    • Per Seattle Method, "An information block (a.k.a. block, fact set) is a helpful unit of information that describes the logic of a set is a set of facts which go together (tend to be cohesive and share a certain common nature) for some specific purpose within a report."
    • Per OIM, undefined.
    • Per XBRL, implied but undefined.
    • Per SBRM (page 23 and 24), "Fact Sets are groupings of individual Facts within a Fragment. These groupings: Enable the logical organization of related data points; Are tied to the Concept Arrangement Patterns and Member Arrangement Patterns, which define the semantics of the relationships within the group."
  • Concept
  • Period
  • Units
Additional Information:

Comments

Post a Comment

Popular posts from this blog

Overview

Image
Imagine it.  Freedom from drudgery. Freedom from the toil of tedious, repetitive, mundane, monotonous tasks. Far less time needs to be spent fulfilling the role of "data janitor".  Time spent "transaction chasing" is significantly reduced. This overview is an attempt to take the work that I have done to understand XBRL-based reports and back into a framework for explaining those reports to accountants and software engineers building software for accountants.  I am now referring to this as model-driven reporting .   The sources of the information provided below are my " lab notebook " from December 2007 to October 2022; my Digital Financial Reporting blog from October 2022 until January 2025; Mastering XBRL-based Digital Financial Reporting ; and finally my Seattle Method  documentation. What I have tried to do is take the seemingly hundreds of incomplete, far too technical, typically nonstandard explanations that I have come across; take the good/best ide...
Read more

Knowledge Representation Approach

Image
Knowledge representation is simply organizing knowledge related to some area of knowledge into some physical form.  A knowledge representation provides an explanation of or description of the nature and structure of something. There are a number of different approaches that a knowledge representation might take, each approach having a different level of expressivity and reasoning capability.  These different knowledge representation approaches form a spectrum.  The following is a graphic which shows the expressivity and reasoning capability of different knowledge representation approaches: The following is a brief description of each of the different knowledge representation approaches which will help you understand the relative expressivity and reasoning capability of each approach: Name authority : A name authority provides what amounts to a dictionary or list which amounts to a flat inventory of terms with no relations expressed between the terms. This can be thought...
Read more

Complexity

Image
The world is complex.  But sometimes humans can come together, leveraging the power of agreement, and agree enough to create something useful in meeting some specific important aim and satisfying some agreed upon set of goals and objectives. A kludge is an engineering/computer science term that defines what is best described as a workaround or quick-and-dirty solution that is typically clumsy, inelegant, inefficient, difficult to extend and hard to maintain; but it gets the job done. The nautical term for a kludge is jury rig. By contrast, elegance is beauty that shows unusual effectiveness, grace, and simplicity. The alternative to being a kludge is  elegant simplicity . Elegant simplicity is achieved through complexity via hard work an, clever ideas, etc. Gall's Law states that a complex system that works is invariably found to have evolved from a simple system that worked. This principle emphasizes that effective complex systems develop from simpler, functio...
Read more