[OpenSpending] XBRL for Local Government Financial Reporting: A Response to Friedrich from the Father of XBRL

Sun Sep 15 11:26:12 UTC 2013

Hi Marc,

Thanks a lot for seeking out the comments from Charles and for sharing
them. Really enjoy seeing this debate catch on!

I'd find it great to see this comment reposted to OpenSpending as a
continuation of the debate. Could you possibly seek the approval of Charles
to post it on the blog?

Anders

On 14 September 2013 21:54, Marc Joffe <marc at publicsectorcredit.org> wrote:

> I shared Friedrich’s article with Charles Hoffman, the father of XBRL.  He
> sent me a very thoughtful response by private email, and allowed me to
> share it with this list.  Much of this content will appear on Tabb Forum in
> the next week or two.****
>
> ** **
>
> Marc****
>
> ** **
>
> From Charles Hoffman:****
>
> ** **
>
> XBRL has unfortunately earned the reputation it has because of (a) flaws
> in the way some regulators implement XBRL and (b) misunderstands of the
> business people promoting XBRL.  This is very consistent with what Gartner
> calls the “hype cycle”.  See this:
> http://irwebreport.com/20110309/xbrl-investor-relations/****
>
> ** **
>
> The following are the realities and truths which should be considered
> summarized as succinctly as possible. (You can see the details here on my
> blog:****
>
>
> http://xbrl.squarespace.com/journal/2013/3/1/achieving-meaningful-exchange-of-information.html)
> ****
>
> ** **
>
> POINT #1: Achieving meaningful exchange: ****
>
> “The only way a meaningful exchange of information can occur is the prior
> existence of agreed upon semantics, syntax, and workflow/process rules.”**
> **
>
> This video made available by HL7 explains this in more detail:
> http://xbrl.squarespace.com/journal/2010/8/29/into-to-hl7-video-can-help-you-understand-xbrl.html
> ****
>
> ** **
>
> POINT #2: Formality****
>
> If you consider POINT #1, the “rules” can be somewhat of a bottomless
> pit.  A balance needs to be achieved between practicality (something
> actually works) and “formality” (spending so much time creating rules and
> making things so complex that no one could ever use the system).  A
> practical balance needs to be achieved.****
>
> ** **
>
> POINT #3: Expressiveness****
>
> While it is true that CSV has been around a long time, it is easy to use,
> there is lots of support….CSV is not very expressive.  CSV is a “flat”
> tabular structure, two dimensional.  Information is “n” dimensional (could
> have many dimensions). An OWL ontology is WAY, WAY more expressive in terms
> of creating rules to make sure the information is correct (i.e. POINT #1),
> but it is much more complicated because of that expressiveness.****
>
> ** **
>
> POINT #4: Complexity****
>
> While “complexity” can never be removed from a system, the complexity CAN
> be moved. What I mean by this is that while it is hard to create something
> like an OWL ontology, computer software can shield business users from the
> complexity in many, many different ways.  One example is the use of
> “patterns”.  Another is using “application profiles”. Another is using the
> 80/20 rule in terms of creating business rules to assure information
> quality.  I could go on and on about this and show you many, many
> examples.  Fundamentally this all boils down to the this one fact: “XBRL
> software vendors” are building the wrong software; they have built XBRL
> technical syntax editors instead of “digital financial reporting”
> applications or “digital business reporting” applications.  This problem is
> understood by some software vendors who are now building the correct
> software, others are understanding, everyone will be forced to move in this
> direction due to market pressure.****
>
> ** **
>
> POINT #5: Guidance-based, semantic-oriented, model-driven, business report
> authoring enabled by “semantic web” technologies****
>
> Authoring business reports in the future will be as different as the
> difference between creating a photograph when you used a darkroom filled
> with smelly and chemicals as contrast to using “Photoshop”.  What you can
> do with a business report will also be as different as what you can do with
> a photograph printed on a piece of paper and a photograph expressed
> digitally.  The key is “metadata” and applications which understand and
> therefore leverage that metadata.  For example, Microsoft Word knows ZERO
> about creating a financial report.  Nothing.  Guidance-based,
> semantic-oriented, model-driven financial report authoring tools (think
> TurboTax) will have:****
>
> •           Knowledge baked in****
>
> •           New knowledge can be inferred/added****
>
> •           Agility to adapt to ever-changing conditions****
>
> •           Semi-automated data integration****
>
> •            Machine intelligence ****
>
> ** **
>
> You may not be able to imagine these applications, or maybe you can.  But
> when you see an application working correctly, leveraging a rich set of
> metadata (which you cannot even express using CSV files), it will be very,
> very easy to grasp these ideas. Read the documents linked do on this blog
> post:
> http://xbrl.squarespace.com/journal/2013/1/2/smart-dataapplications.html *
> ***
>
> ** **
>
> XBRL is only part of a much, much broader trend of digital business
> reporting and digital financial reporting.  That is part of an even bigger
> trend, “digital”.  Electronic medical records is an example of the much
> broader trend.  Electronic medical records has many of the same issues as
> what the SEC is trying to do with XBRL-based financial filings.  The
> accounting profession and SEC is much, much further down the path than
> electronic medical records from what I can see.  Electronic medical records
> (EMR) are not “interoperable” or exchangeable between systems yet (XBRL
> is).  There is no international standard for EMR (there is for financial
> reporting, XBRL).****
>
> ** **
>
> Generally, people are having the WRONG DISCUSSION!!!  They are discussing
> syntax (i.e. CSV, JSON, XML, etc.) and they SHOULD be discussing “how the
> heck are we going to articulate and management semantics”.  THAT is the
> discussion which needs to occur.  This is VERY, VERY useful stuff.  This is
> not about saying that CSV is bad and that XBRL is good.  They are two
> different tools for different problems.  Using the wrong tool to solve a
> problem is bad as well as inappropriately using a tool is bad!****
>
> ** **
>
> The “Government Linked Data Working Group”:
> http://www.w3.org/2011/gld/wiki/Main_Page. That is another approach:
> RDF/OWL.  Not good or bad, just different.****
>
> ** **
>
> The goal as I see this is success.  Success means (for business people)
> cost effective, easy to use, effective, robust, reliable, repeatable,
> predictable, scalable, secure (when necessary), auditable (when necessary),
> practical, business information exchange by business users between business
> systems.  ****
>
> _______________________________________________
> openspending mailing list
> openspending at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openspending
> Unsubscribe: http://lists.okfn.org/mailman/options/openspending
>
>

-- 
*

Anders Pedersen

Community Coordinator  |  skype: anpehej  |  @anpe <https://twitter.com/>

The Open Knowledge Foundation <http://okfn.org/>

Empowering through Open Knowledge

http://okfn.org/  |  @okfn <http://twitter.com/OKFN>  |  OKF on
Facebook<https://www.facebook.com/OKFNetwork> |
Blog <http://blog.okfn.org/>  |  Newsletter<http://okfn.org/about/newsletter>

*

OpenSpending | http://openspending.org |
@openspending<http://twitter.com/openspending>

School of Data | http://schoolofdata.org |
@schoolofdata<http://twitter.com/schoolofdata>

*

**

*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending/attachments/20130915/296631d2/attachment.html>