Also - while I appreciate Wikipedia generally, a gentleman from France has set himself up as the keeper of the XBRL page and has made it his full time job to keep the XBRL page to HIS message; it is not a reliable - or at least complete - source of information. Likewise, the Just Systems video of "XBRL for Plain English" is focused ENTIRELY on the financial reporting story and misses the broader, and more important in my view, message of integration, not just paving the eFiling and eReporting cow path.

ALDO - Linked Data does not currently meet the business requirements of the task. However, the W3C has established an XBRL fellow and investigation of the use of OWL/RDF is underway. You may wish to Google '"linked data" xbrl' for various efforts in this area. Open Link software has done some work in this space, whatever the quality of their work is. By the way, your posting your opoinion here doesn't really accomplish much; why not post to one of the public XBRL mailing lists instead? You say "For the nnnth time" - a Google does not bring up your name + XBRL anywhere other than here. Where are the other nnn - 1 times?

I believe Linked Data DOES meet your business requirements.

Can you be more specific?

Whatever can be built on XML can be built on RDF.

I am aware of the collaboration efforts and I use both techs on a daily basis.

By using Linked Data / RDF you'd gain:

* Access to maturing family of second generation middleware
* Identifiers as endpoints that can be dereferenced ( w/o using proprietary protocols and conventions )
* Automatic mashing of the data ( both XBRL and any other, i.e corporate data or DBPedia )
* Querying over a graph based model using a well understood and characterized query language ( more expressive and powerful than the "X.." family )
** Business reporting and aggregates are not part of the standard but they can be widely found. Moving a quad from-to relational models or OLAP is also quite straighforward.
* Alignment with a rising community that is integrating RDF into many realms ( spreadsheets, social networks, desktop environments, etc )
* Lastly, the most valuable: Seren

The current financial turmoil is rooted in our inability to integrate *beyond* the expected lines. Not simply the complications of operating *within* the expected lines.
Otherwise we never improve the paradigm ( until it proves itself flawed and you have Greenspan putting up a surprise face on national TV ).

This is a complex system, we need to see data in context.

Assume you have an epidemic hitting a certain region. What is the financial footprint?
Who benefits?
Who suffers?
Can we understand the impact this has across borders, value chains, industries and throghout time? Can we see the ripples?

If we operate on closed systems designed to reflect reality on a certain paradigmatic surface, we will always miss part of the picture.

This is where Linked Data comes into scene.

With linked data you could bring together biological data, protein data, geographic data and demographics ( which wer

My regrets for not Googling you earlier; I had not realized you were already familiar/associated with Open Link and its representatives, and a strong supporter.

I should make my argument short. LINKED DATA is great, and I really appreciate TBL's vision. LINKED DATA is first and foremost about (his rule 1) identifying everything with a URI. Rule 2, serve it up with a URI, rule 3, serve it up on the Web against a URI.

That is NOT the (whole) XBRL story. XBRL can contribute to information made available in that way, but that was/is not the primary business requirement of XBRL. XBRL is about improving information throughout the Business Reporting Supply Chain. Like an iceberg, only the tip of the BRSC is visible (the financial statements and other PUBLIC reports). Much of it is submerged (the data related to the processes to FEED those end reports, as well as run the companies, and certain forms and reports that go to auditors, regulators, administrators and other "close" parties). Much of XBRL relates to information that never has a URI, never hits the web; XBRL was from the beginning going to be PAYLOAD ONLY, to be handled and transported and secured however necessary. OWL, RFD, LINKED DATA are simply not the appropriate basis for this overall development, although harmonization between XBRL and LINKED DATA approaches for the publicly available information (or information available in a Web environment in a closed arena) can have great value as well. We must improve the entire BRSC in order to make that information that is publicly available the most useful.

- - -

I should stop there, but I can't.

You make many assumptions in your response. Let's start with:

"I believe Linked Data DOES meet your business requirements."

I don't believe so. You are concentrating solely on publicly available information on the Web and the needs of society. Those needs are good. But they are only a small part of the larger picture - they have very little to do with the DEFINED business requirements behind the development of XBRL - those public needs are just what YOU think the requirements might be, an enhanced group of users. Is LINKED DATA appropriate to be general payload, as suitable for private ETL as for public reports?

Moving on to:

"About OpenLink, you are stating that their works is low quality."

I CERTAINLY did not, especially explicitly. I said, "whatever the quality of their work is." I am aware of people who question the quality of their work, their objectivity, and the effect they have on the public, especially in their championing OWL/RDF/LINKED DATA at any cost and in every situation. I do not endorse nor flame against them, their efforts or especially their products. I do not question their motives or contributions to standards space. There is evidence that they promote LINKED DATA at any expense without understanding the rationale behind other approaches, much as I believe you have done so far.

You say:

"Whatever can be built on XML can be built on RDF."

Simply not true. What is RDF? "The Resource Description Framework (RDF) is a language for representing information about resources in the World Wide Web." What if the resources AREN'T ON THE WORLD WIDE WEB? XBRL content is not limited to http/URI accessible information. It is payload that can be sent via email, exchanged via web services, passed from one party to another on a USB Flash drive. It is private travel expense information that might go from one division to another, a tax return that should only go to the tax administrator. It is a standard extract from a small business bookkeeper to give to a small business owner, or a company to send to its bank. Yes, it is also and highly visibly public information AS WELL; but a holistic solution was desired, not one optimized for a single role in the BRSC.

You seem to say that I am saying the RDF could not have been a useful approach. I am not saying that either. I AM saying that XBRL was built on certain defined BUSINESS requirements, about integrating the business reporting supply chain from first transaction to and through end reporting, much of which may NEVER see the light of day, is never available via http, is never served up on the Web. Not the broad "goodness to mankind" that you bring up, but specific business and technical REQUIREMENTS that were developed by the consortium and then a Specification (and modular extensions) developed to meet that need, considering RDF, considering many other potential parts of a solution. It was also based on the (perceived) strengths of each solution at the time. It is about being suitable payload for a variety of environments. It is about EXTENSIBILITY - letting reporting companies say, "I am just like the standard, but different in this specific way". It is about associating facts with human readable labels and definitions as well as authoritative guidance, of associating concepts with others in a calculation relationship. And it turned into a standardization on W3C recommendations, using XML tooling which is throughout corporate environments, embedded in DESKTOP applications everywhere and has been for years (not software which is limited to second generation middleware today).

What do we know about OWL? Not really there to help validate documents. (says the Primer, http://www.w3.org/2007/OWL/wiki/Primer). A MAJOR business requirement of XBRL is for the documents to be valid, meet the needs of regulators, useful for compliance filings. Would OWL have been a useful approach for the FDIC/FFIEC in the United States, which drastically improved the quality of filings by moving validation to the "front door"? I am just seeing first drafts of the RIF group coming out; there simply aren't standardized validation or rules for LINKED DATA solutions right now.

What else do we know about OWL? Letting the OWL2 documentation speak for itself:

"This report underlined that one of the omissions in the OWL language that users complain about most often is poor representation of numeric expressions. Almost all groups, except for those developing traditional medical terminologies, sorely need to be able to express quantitative information. Typical examples include the length between 1mm and 2mm, age greater than 18 years, pressure in the range of 1030mb to 1035mb. Such range declarations are needed to classify individuals and to build class definitions such as Adult, and should therefore be supported by reasoners. User base points out that the current OWL datatype formalism is much too weak to support most real world applications and that many potential users therefore cannot adopt OWL."

This from http://www.w3.org/2007/OWL/wiki/New_Features_and_Rationale

Huh - OWL says that things related to numbers - LIKE FINANCIAL REPORTING!!! - may not have been properly served in the past.

Also, the ability to ANNOTATE anything was also very weak in the prior version of OWL, per the same document. And yet annotations and understanding are a major part of XBRL, such as human readable labels and definitions in 24 pre-defined roles, links to authoritative references and more.

(Do you understand that XBRL is MORE than XML Schema? That the use of XLink provides more hierarchical relationships and pointers to resources?)

What were some of the business requirements, and did LINKED DATA provide a solution at December 2003, when the Specification was published?

Is all of XBRL data external and on the Web? Does all XBRL data have a URI? NO. XBRL was designed to provide a common specification to integrate the ENTIRE business reporting supply chain, to serve as payload that could be sent over the web, via email, any way. Much of the data that will be represented with XBRL will be internal to a company, private, being used to move from one machine to another, not long lived, never available via http or https or at all. Is LINKED DATA appropriate for machine to machine data transfer, such as traditional EDI? XBRL is not just publicly available financial information, ready to be mashed up. It is also internal operational details and accounting information (XBRL GL) that may never see the light of day but be critical for ERP integration. Is LINKED DATA really appropriate here? It is tax returns, meant to be privately delivered to the tax administration. Is that appropriate for LINKED DATA? It is audit documentation meant only for audit workflow and to be in a standardized format should there be a review. Is that appropriate LINKED DATA?

XML has a mature series of SECURITY standards, such as XML Signature and XML Encryption. As XBRL is NOT only about publicly available data on the Web, but about payload to be used in many environments, there are many cases where you may wish a batch of information to selectively unfold to different communities - a tax filing that opens in different ways to different divisions within a tax agency, a group of accounting transactions where the results from the department of agriculture are readable by all but those from an intelligence agency only unfold to those with three starts or above. There is little SECURITY thought in the OWL/RDF world. I know of some efforts in the US government where OWL plus security is being explored, but LINKED DATA is not in anyway appropriate for taking data and turning it into a secure document.

We have already said that OWL says of itself that it is not proscriptive and is less suitable for validation, per the Primer. And yet a goal of XBRL is for groups to agree on what is the information that can and must be produced in certain areas of business reporting. It also provides a STANDARDIZED way to defining the authoritative and helpful legal and practical guidance (references) for each fact. It also formalizes 24 specific meanings of human readable labels for each fact in all of the ISO languages. You could potentially do that with OWL/RDF, but you would need to come together to AGREE on how to make that happen. It doesn't come free moving to RDF or LINKED DATA.

To meet the BUSINESS REQUIREMENT in certain areas, a formal method of EXTENSIBILITY is required - "our reporting is just like the more global reporting, and here is EXACTLY how we differ." XBRL formalizes the "bread crumbs" on how to modify the STANDARD for company specific methods. Perhaps you could do that with RDF, but it is something where a group would have to come together to AGREE to that purpose.

Your arguments concentrate only on the ease of consumption side. They speak about a state of application readiness ("second generation middleware") that in no WAY approaches the state of XML readiness in commercial environments.

I said I should have stopped at my initial comment. I will do so now.

I notice my comments haven't surfaced here, while the comments make their way through the system here, I really take issue with your comments:

I CERTAINLY did not, especially explicitly. I said, "whatever the quality of their work is." I am aware of people who question the quality of their work, their objectivity, and the effect they have on the public, especially in their championing OWL/RDF/LINKED DATA at any cost and in every situation. I do not endorse nor flame against them, their efforts or especially their products. I do not question their motives or contributions to standards space. There is evidence that they promote LINKED DATA at any expense without understanding the rationale behind other approaches, much as I believe you have done so far.
>>

Please be specific about "Quality of Work".
Please be specific about "Linked Data Promotion at all costs".

If you can tell me a scenario where Linked Data is irrelevant I desperately seek your enlightenment.

btw - My passion is fundamentally about Open Access to Data across all computing boundaries without compromising security, privacy, or choice on the part of users or developers.

I am sure Google can help you discern who I am and what my motivations are, so please do not misrepresent me or OpenLink Software without putting facts in focus. It's simply unfair to do that!

Kingsley

Please stop second guessing my intentions, leaving incomplete phrases and suggestions. This is not healthy debate.
If you are going to engage in this kind of public discrediting, at least provide your name and affiliation.

1. I am NOT defending any particular entity with a bias. *You* brought one up and incorrectly "framed" them ( and continue to do it ).

2. I am not stating that XML should not be used. I am sure that much thought has gone into the current framework, and it makes no sense at all to throw it away. RDF can be serialized as XML and contain XML. You can mix and match both. So I repeat: "everything can be done".

3. URIs needn't be on the open web. They are, in essence, a global naming scheme ( with all the benefits that provides when it comes to integration ). With respect to security, the fact that there is one web does not preclude you from partitioning it into different communicational channels through different access strategies. That's how the web is built today ( private/pu

Seeing as this debate has become somewhat heated I'll state upfront I'm a developer (aka "programmer") and occasional architect of largely behind-the-firewall information systems. RDF is something I've been reading about and following for some time, since I believe it has a great deal of potential. After seeing tools developing at a pace and seeing a (behind-the-firewall) business need I once recommended and properly investigated RDF with my team mates and we found the documentation and open source tools were not quite ready for us.

I'm neither a vendor or an adopter to any great extent. I did RDFa enable some pages on feelitlive.com for the benefit of Search Monkey. Probably I will adopt linked OPEN data and SPARQL to assist with some internal record linkage issues in the next 6 months. I'm not at all familiar with XBRL, I know only what is related above, but the notion that XBRL or RDF could have stopped the credit crunch is fascinating because recessions suck, so I've attempted to follow along.

So, there you have my background.

AFAICT Aldo's response is pretty complete, but I would like to point out - for the benefit of anyone stumbling into this public space without being familiar with either technology - that in fact some of the things you say were business requirements for XBRL are actually advantages for RDF and linked data as a model.

RDF is very extensible, terms can be defined privately or publicly, unilaterally or by committee. It is primarily about links between entities. Terms can be combined very easily, giving organic extensibility. It is not true that all data in RDF has to have a URL and URL-free data could indeed be used with and inside Linked Data (i.e RDF with URLs in it). Not all URLs in RDF data have to be HTTP URLs either.

Yes it is true that people will eventually need to agree things together as a group, locally, politically or as an industry - as has apparently been done for XBRL. This sounds more like a similarity than a difference.

As for exchange of documents and ETL, I'd venture that if you expect a document use XML, but if you expect data then use RDF and if you want to get data from documents use both. For ETL, of course, you have data and having looked at similar requirements in some depth I'd much prefer RDF over XML for all manner of detailed technical reasons which I won't bore you with.

Also, one of the core messages circulating about Linked Data is that you do NOT need to change the way you manage data - mostly you'd just proxy your existing data-stores or do on-the-fly document parsing. Reading just your description of XBRL it sounds as though you need to convert your entire enterprise to use XBRL properly whereas RDF is simply another tool to add. That's quite a contrast. Were I reading this discussion with a real business need and my existing knowledge of RDF then I'd start to look at exactly how I can best combine RDF *and* XBRL into a solution without throwing out my existing software. I get a vague impression that this would limit the benefit of XBRL to regulatory reporting, which seems a shame for XBRL given the way it has been promoted here.

I'll conclude by pointing out that the article which we're discussing contained an analogy about uniquely tagged Geese. RDF is precisely a generalisation of uniquely describing and tagging Geese, with the difference that it's using the nearest thing to a universal ID we've ever invented - URLs - to do the tagging. If you accept that goose tagging is a core benefit to XBRL then you really have to wonder why XBRL experts are arguing with RDF experts instead of studying and incorporating RDF!

Let's have more incorporating and less arguing please, because there is a recession to be sorted out.

thanks,
Simon

... RDF is something I've been reading about and following for some time, since I believe it has a great deal of potential ...

XM> Me too. In my reading, and talking, and working, I have just found out that it's just not the answer to _everything_, all the time - or even everything called "data", all the time. It is an answer to some important things.

... the documentation and open source tools were not quite ready for us ...

XM> Agreed. That's a problem. Also, none of the active vendors within XBRL circles, including the ERP vendors, were/are RDF people. Also, none of the prospective users prioritized anything other than XML as a format. Well, the academic community was pushing for UML (and maybe XML) approaches, not RDF approaches.

On top of that, I know of very few Semantic Web (SW) people who believe that RDF could claim widespread commercial use before this year (if you believe it has hit this year). If the SEC can't mandate something until it is in the mainstream ... could it have mandated RDF this year?

... but the notion that XBRL or RDF could have stopped the credit crunch is fascinating because recessions suck, so I've attempted to follow along ...

XM> I think it is only PART of that good breakfast. Agree that recessions suck, as does fraud and other malfeasance. Inefficiency, redundancy and waste I could do without too.

... AFAICT Aldo's response is pretty complete ...

XM> I appreciate your opinion, but I still think he misses the mark on many of the points, as I see it. And I continue to be accused of things that just ain't true.

Regarding missing the mark, as an example:
Security at the network/system level doesn't solve the business requirement: one file (or, more appropriately, collection of files) needs to selectively open to different audiences, the creation of docu-data, the best of a database and the best of a document, crossing networks, retaining its integrity wherever it goes. Authentication (e.g., digital signatures) and secrecy (e.g., XML encryption) need to follow the facts as they pass across networks, are archived, and are used later, first within and then across organizations. I have not heard that RDF adds to this capability in any way.

.. but I would like to point out - for the benefit of anyone stumbling into this public space without being familiar with either technology - that in fact some of the things you say were business requirements for XBRL are actually advantages for RDF and linked data as a model ...

XM> I still think the key word is "some"; even if OWL 2 were available in 2003, with a wide variety of open source and commercial applications available, it would not have solved everything.

... It is not true that all data in RDF has to have a URL and URL-free data could indeed be used with and inside Linked Data (i.e RDF with URLs in it). Not all URLs in RDF data have to be HTTP URLs either ...

XM> That's helpful to understand, if non-intuitive. And TBL might disagree with the HTTP URLs comment (http://www.w3.org/DesignIssues/LinkedData.html). But I still have not seen how RDF makes transferring the content of a 30 GB Oracle database between a company and the auditor any better than a standard defined using the XBRL Specification (or a pre-defined flat ASCII file). I am hearing workarounds on how RDF COULD be used, rather than hearing proofs on why - for non-public, non-Web based data, for example - it SHOULD be used. TBL's rule #3 is to serve it up on the Web. That just isn't relevant for MUCH of the business case of XBRL. Absolutely NO QUESTION about public data. MUCH question about the "below the water level" data on the "iceberg" of corporate reporting.

... Yes it is true that people will eventually need to agree things together as a group, locally, politically or as an industry - as has apparently been done for XBRL. This sounds more like a similarity than a difference ...

XM> Sure - any approach cannot just come "out of the box". The XML/XBRL part has a 10 year head start; not that the lessons learned couldn't be quickly leveraged with a Semantic Web approach.

... As for exchange of documents and ETL, I'd venture that if you expect a document use XML, but if you expect data then use RDF ...

XM> That's sort of the crux of the whole debate, isn't it? Why do you think RDF for a vendor master file is superior to XML Schema (plus linkbases) for moving that vendor master file from System A to System B on a consistent basis? (I don't normally think of ETL involving documents, unless you mean transactions captured as source documents.) And why XML for the documents, but not the data? Isn't everyone thrilled that search engine vendors showed their use of SW technologies in San Jose? Isn't that serving up documents, and not data?

Why, for transferring data from point A to point B, when you aren't querying anything, traversing anything, and you just want to know the data is going to import without validation problems, is RDF better than XML Schema? Or CSV? Doesn't the addition of URIs add overhead and inflate the file (even more than XML alone does) with no (obvious to me) benefit?

... and if you want to get data from documents use both ...

XM> As appropriate, makes sense.

... For ETL, of course, you have data and having looked at similar requirements in some depth I'd much prefer RDF over XML for all manner of detailed technical reasons which I won't bore you with ...

XM> That's what I would like to be bored with. Why should the local tax regulator want an extract of your company's accounting system, sent from them to you on a secure 64 GB thumb drive, in RDF rather than CSV with agreed upon headers, against an XML schema, or any other agreed upon format? Why would the IRS want your tax return in RDF instead of XML? Or express their needs with an ontology language instead of XML Schema - or, even better, XBRL?

... Also, one of the core messages circulating about Linked Data is that you do NOT need to change the way you manage data - mostly you'd just proxy your existing data-stores or do on-the-fly document parsing. Reading just your description of XBRL it sounds as though you need to convert your entire enterprise to use XBRL properly whereas RDF is simply another tool to add ...

XM> My apologies if you got that from what I said. While there is value in being able to see all of your systems as XBRL/XBRL GL (for corporate governance, metadata management, applying rules across systems, discovery, archival, et. al.), XBRL can be used to map info on-the-fly, and just use XBRL/XBRL GL for standard import/export.

... Were I reading this discussion with a real business need and my existing knowledge of RDF then I'd start to look at exactly how I can best combine RDF *and* XBRL into a solution without throwing out my existing software ...

XM> An excellent thing to do - and as a developer, something you could come up with an insane application to put into the market and say, "See! This is why RDF is so important and shows the benefits you wouldn't have otherwise gleaned."

Typical developers in this space - not so. Business users and developers in this space - not so.

Whether RDF or XBRL Spec or UML/XMI or whatever, they are just tools to meet the business need; not a stand to live and die on.

... I get a vague impression that this would limit the benefit of XBRL to regulatory reporting, which seems a shame for XBRL given the way it has been promoted here ...

XM> I may be misunderstanding this. Why would it limit the benefit? Would XBRL Spec limit the use to regulatory reporting, or RDF, or combining the two?

... I'll conclude by pointing out that the article which we're discussing contained an analogy about uniquely tagged Geese. RDF is precisely a generalisation of uniquely describing and tagging Geese, with the difference that it's using the nearest thing to a universal ID we've ever invented - URLs - to do the tagging. If you accept that goose tagging is a core benefit to XBRL then you really have to wonder why XBRL experts are arguing with RDF experts instead of studying and incorporating RDF! ...

XM> Petulantly, "he started it first" by lobbing the "For the nnnth time. Please consider using L I N K E D D A T A as foundation." statement.

And there are no XBRL experts here, just me, the XMeister.

And the "arguing" is because certain LINKED DATA people make great claims but never PROVE their approach can solve the broader, both external and INTERNAL, holistic issues XBRL is trying to solve (it AIN'T just financial statements, or public information, or web-based information, it is about benefits to EVERYONE involved, including the corporate filers; security can't be limited to network-based, but needs to be at the document level, etc.)

Folks like me ARE trying to delve into OWL, RDF, SPARQL and other Semantic Web technologies.

XBRL has experts (not me!) with multiple Comp Sci degrees at advanced levels who evaluated, analyzed, and went the way they did with solid reasoning. The experts aren't incorporating RDF because, after their studying, they have seen no compelling argument to do so.

Fortunately, as I noted at the beginning, the W3C has an XBRL fellow who is going to help make the potential benefits and costs of incorporating RDF known to the community. Then the arguments can cease.

Regarding the geese; it actually has NOT been a primary business requirement to date (with much dissension) that the geese will keep their identity across areas of business reporting. There are different taxonomies for US, Canada, Germany, Japan, IFRS and - currently - no official ties between them. I understand that TBL had recommended using ontological approaches to help cross-GAAP definitions, and I certainly see some benefit to the possibility. But - to many an XBRL enthusiast's dismay - said geese tagging is NOT a driving business requirement within XBRL development circles. And as each goose has strong ties to definitions, specific authoritative reference materials and practical guidance, and much more, those geese are very heavily tied to a specific taxonomy.

... Let's have more incorporating and less arguing please, because there is a recession to be sorted out ...

XM> No arguing here. Just looking for answers, and not platitudes.

# # #

Wouldn't it be nice if "@XMeister" was a conduit to a description of who you are? By this I mean it exposed your profile page? In a nutshell I wouldn't have to google in vain on the literal pattern which simple reveal nothing.

Back to the topic at hand, XBRL, Data Access, and Data Joining. XBRL is simply an XML based approach to modeling financial reports. A financial report is a document about financial entities such as balance sheets, profit and loss statements, statements of applications of funds, and so on.

If every entity in an XBRL instance document has an identifier, the relationships between these financial entities becomes clearer and navigating the relationship graph becomes feasible (what you do when you are looking for stuff in any realm).

If every entity in an XBRL instance document has an HTTP based Identifier, we end up with the ability to reference said entities across an HTTP based network (external or internal). Likewise, the aforementioned graph is no longer localized (whic

Link: http://hitachidatainteractive.com/2007/01/16/the-entity-problem/ -- Which basically unveils the identity issue which Linked Data URIs address circa. 2007.

Kingsley

**I mistakenly posted these comments to another ReadWrite thread when I first encountered your comments**

Here are Aldo's points in a nutshell:

1. XBRL is an XML based notation for expressing Financial Reporting Data

2. XBRL is a representation of Data

3. RDF is a framework in which all Data items are Resources (i.e. useful things that have Identity) or Data Objects (or Entities) and these Items/Objects/Entities create a "Mesh" (a Graph) based on their Attribute values and/or Relationships with other Items/Objects/Entities.

XBRL instance data can be presented in RDF Linked Data form such that each item in the XBRL report becomes an Entity endowed with an Identifier.

In the case of Linked Data, the Identifiers incorporate the HTTP protocol such that each Object/Item/Entity is de-referencable over an HTTP network ( which does not always mean the public World Wide Web).

Linked Data is simply about a continuation of the long desired pursuit of platform independent distributed data objects.

Back to XBRL, we already convert XBRL instance docs (XML) into RDF by the use of RDFizer or RDFization middleware. What this means is that right now we can already build Entity/Object graphs from any XBRL document "on the fly" so that you can explore XBRL data object in granular form.

Some live examples:

1. http://demo.openlinksw.com/about/html/http://www.sec.gov/Archives/edgar/data/40545/000004054508000065/ge-20080930.xml%23GE_CONS_3Q08 - Part of GE's XBRL Instance Data in RDF Linked Data form
2. http://dbpedia.org/resource/Linked_Data - About Linked Data from DBpedia (which is an RDFization of Wikipedia)

I hope this clear up matters. Yes, as you say, you can "Mash" when dealing with XML and the rest of the Web 2.0 stack. Just bear in mind that Linked Data is simply about adding the ability to "Mesh" to the mix since the data is structured at a more granular level.

Kingsley

@XBRLmeister its clear that the financial reporting is only "the tip of the iceberg" (para 5) for xbrl use. But its the one that is going to create the necessary media moment and initial buy-in.

Comparing the geese across flocks (taxonomies, jurisdictions) is a holy grail of the language. It is actively being pursued so that companies can compete for attention in global markets

@Kingsley Idehen thanks for the links and succinct explanations

@Simon Gibbs I wouldn't dare venture that xbrl could prevent such a crisis. But I would expect that directors of companies and analysts would have been able to pull up complex reports and analysis simpler if the data was mashed up to a dashboard. Thereafter, triggers and other threshold alerts could be set