The XML Business Reporting Language (XBRL) is a standard for business and financial information reporting. It is based on XML so instance documents based on XBRL, e.g. a quarterly report, are highly constrained by the XML document-oriented nature. This makes more difficult to perform queries that mix information from filings from different dates, companies, or accounting principles than with a formalism based on a graph model instead of a tree model. Semantic Web technologies provide a graph model that facilitates mashing-up different XBRL sources. We have put into practice this approach mapping the XBRL filings available from the SEC's EDGAR program to Resource Description Framework (RDF) and the XML Schema taxonomies these filings are based on to Web Ontology Language (OWL). The resulting semantic metadata, though highly tied to the XML structure it is mapped from, benefits from Semantic Web technologies and tools in order to facilitate integration and crossquerying, even together with other parts of the Web of Linked Data.
XBRL (eXtensible Business Reporting Language) is an XML
language intended for modeling, exchanging and automatically
processing business and financial information. XBRL is starting
to be deployed in many different scenarios. For instance, there is
the EDGAR [
It performs automated collection, validation, indexing, acceptance and forwarding of submissions by companies and others who are required by law to file forms with the SEC. Filers may choose to voluntarily submit documents in XBRL format to accompany certain official filings. Three dozen companies, representing more than $1 trillion of market value, have joined the SEC's XBRL test group.
However, we have observed limited support for cross analysis of financial information in XBRL tools and applications, as it is detailed in the Related Work Section. This is not just among data based on different accounting principles, which are represented in XBRL using taxonomies. It even happens when comparing filings
XBRL is based on two kinds of documents, instance documents and taxonomies. Instance documents report business facts and point to a set of taxonomies, which define the meaning of these facts, e.g. under what accounting principles they hold, what other facts they related to or what kind of things do they refer to.
More concretely, a XBRL instance document contains business Facts. An example of a Fact could be “sales in the last quarter”. If the Fact is simple valued, like “the long term debt is 350,000” whose value is just a number, it is called Item. If the Fact has a more complex value, like “for the preferred stock, the preferred stock par value per share is 0 and the preferred stock shares authorized is 2000”, it is called Tuple.
Items are represented in XBRL as a single XML element with the value as its content while Tuples are represented by XML elements containing nested Items or Tuples, i.e. subelements. However, facts are not isolated entities and it is not enough to provide its value, it is also necessary to contextualize them. Consequently, more entities are introduced in the XBRL model: • Context: it defines the entity (e.g. company or individual) to which the fact applies, the period of time the fact is relevant and an optional scenario. Contexts are referenced from Facts using the “contextRef” attribute, which specifies that the given Fact is valid for the Context entity, period and scenario. • Unit: it defines a unit of measure, such as “USD” or “shares”.
They are referenced from Facts using the “unitRef” attribute. • Reference: The kinds of facts under consideration are defined by taxonomies, which specify their meaning. These kinds of facts are then used in instance documents and linked to their definition in the taxonomies, typically through schema references.
The a.) row of Table 1 shows part of an instance document from the EDGAR program that contains a Context element which defines a company, a time period and the scenario “unaudited”. Then, there is a Fact that holds in that context. The Fact references the Context and its value unit, while their content is the actual numeric value.
Taxonomies are the other kind of XBRL document. A taxonomy defines a hierarchy of concepts, basically kinds of Facts, and captures part of their intended meaning. In XBRL there is a set of base taxonomies that define the core concepts and other ones that extend them in order to particularize these concepts for concrete accounting principles, application domains, etc. Additionally, it is possible to extend existing taxonomies and accommodate them to particular needs.
Taxonomies are based on XML Schemas, which provides the taxonomy building primitives and the extension mechanisms. Moreover, there are also the linkbases, which allow establishing links beyond the tree structure of a taxonomy by virtue of their use of XLink.
The U.S Securities and Exchange Commission (SEC) offers some online tools that allow interacting with the data available in XBRL form.
There is a tool called Interactive Financial Reports that allows viewing and charting companies financial information. It also provides some functionality that allows comparing different filings and different companies, thought it is hard to use and prone to even the slightest differences between the compared filing facts, even when there is just a name change for facts from filings of the same company. There is also the Financial Explorer, which presents company financial data through very informative diagrams. In this case, it is just possible to show data from one company at a time. Finally, there is the Executive Compensation tool, which allows comparing just two facts, Public Market Capitalization and Revenue, across all filed companies.
Apart from the SEC tools, there are some other XBRL tools, most of them proprietary and with quite high licensing cost. Among them, the Fujitsu XBRL Tools1 should be highlighted because this is one of the most popular ones and it is available for XBRL Consortium members and academic users. The tools comprise taxonomy and instance editors, viewers and validators. The most powerful tool in this set, though still in beta and with many usability problems, is the Instance Dashboard. This application can consume multiple instance documents and, by specifying base taxonomy, users can perform some comparison analysis.
As it has been noted, the main limitation of XBRL tools is their limited support for cross analysis of financial information, not just among data based on different taxonomies, even when comparing filings for different companies based on the same taxonomies. This limitation is inherited from the technologies underlying XBRL, especially XML. XML takes a document oriented approach, where each document presents a tree structure. This makes it difficult for XML-based tools to provide functionalities that blur this separation into documents and that overcome the limitations of a tree structure when mashing-up data from different sources.
Consequently, Semantic Web tools are being considered by
people like Charles Hoffman, the father of XBRL: “This field
[W3C semantic standards] is rich with possibilities and stands as
the next logical step in the natural progression of information
technology to seek a higher value proposition” [
This interest is materializing, and the combination of XBRL and
the Semantic Web has been receiving some attention in different
blogs, mailing lists and web groups [
Moreover, most of these results are specific for some parts of
XBRL. For instance, there is an ontology about financial
information based on XBRL that is specific for investment funds
[
Moreover, both approaches are based on procedural code specially developed in order to extract specific patterns from the XBRL data. Consequently, they are difficult to scale to the whole XBRL specification and affected by even slight changes in it. We propose an approach that, instead of directly processing XBRL data, takes profit from the fact that it is expressed using XML and specified using XML Schemas.
http://www.fujitsu.com/global/services/software/interstage/xbrltools/
http://groups.google.com/group/xbrl-ontology-specification-group
Once all the metadata XML Schemas are available as mapped OWL ontologies, it is time to map the XML metadata that instantiates them. The mapping is based on modeling the XML structure, i.e. a tree, using RDF.
The fundamental translation is between relations, from xsd:elements and xsd:attributes to rdf:Properties. Concretely, owl:ObjectProperties for node to node relations and owl:DatatypeProperties for node to value ones.
Values are kept during the translation as simple types and RDF blank nodes are introduced in the RDF model in order to serve as the source and destination for properties. They will remain blank for the moment until they are enriched with semantic information.
Finally, there is the work by OpenLink Software 3 based on “sponges” that extract semantic metadata from different kinds of content, among them XBRL. This is a quite recent and relevant work towards making XBRL available as linked open data. Therefore, it has been used in the validation section in order to compare the results obtained by our approach.
In order to move existing XBRL instances and taxonomies to the
Semantic Web, and due to the fact that XBRL is based on XML
and XML Schema, we have applied the XML Semantics Reuse
methodology [
The XML Schema to OWL mapping is responsible for capturing the schema semantics. This semantics are determined by the combination of XML Schema constructs. The mapping is based on translating these constructs to the OWL ones that best capture their intended meaning. These translations are detailed in Table 2. complexType|group | attributeGroup element@substitutionGroup rdfs:subPropertyOf complexType//element owl:Restriction
LOD +1M triples
Linking
SPARQL get EDGAR XBRL filings
XSD2OWL
XML2RDF XHTML+ RDFa edit
RDF2HTML RDF2Form
post Rhizomer AJAX The resulting RDF graph model contains all that we can obtain from the XML tree. It is already semantically enriched thanks to the rdf:type relation that connects each RDF property to the owl:ObjectProperty or owl:DatatypeProperty it instantiates. It can be enriched further if the blank nodes are related to the owl:Class that defines the package of properties and associated restrictions they contain, i.e. the corresponding xsd:complexType. This semantic decoration of the graph is formalised using rdf:type relations from blank nodes to the corresponding OWL classes.
First of all, we have generated an ontological infrastructure for the XBRL core, currently XBRL 2.1. It is composed by the ontologies resulting from mapping the XBRL core XML Schemas using the XSD2OWL mapping: XBRL Instance, XBRL Linkbase, XBRL XL and XBRL XLink. Apart from the previous schemas, the EDGAR Standard Taxonomies schemas have been also mapped in order to be able to map the XBRL data submitted to the XBRL voluntary program EDGAR.
Each filing for the companies participating in the EDGAR program contains an XBRL XML file representing the actual financial data and also a specific XML Schema extending the XBRL core. This schema provides specific guides for the corresponding financial data. Both files are mapped using XML2RDF and XSD2OWL respectively.
For instance, for Adobe Systems Inc filing on 2008-07-03, there are the adbe-20080616.xml file containing the instance data and the adbe-20080530.xsd schema for data structures specific for this filing. They are mapped, respectively, to the RDF file for instance data adbe-20080616.rdf and the OWL ontology adbe20080530.owl for the schema.
All the previous ontologies are available from the BizOntos Business Ontologies web page5 and the semantic data for all the processed filings can be queried and browsed from the Semantic XBRL site 6 . Currently, 489 filings have been processed from EDGAR. The combination of all these filings once mapped to RDF amounts slightly more than 1 million triples, concretely 1,023,929 triples.
Part “c.)” of Table 1 shows the RDF metadata resulting from applying the XML2RDF mapping to the XBRL context and facts shown in part “a.)” of the same table. The RDF metadata references classes and properties from the OWL ontology resulting from mapping the XML Schemas used in the XML instance. This includes the XBRL schemas and also those specific for the concrete filing being processes.
Finally, the generated data is published as Linked Open Data in
the World Wide Web. The approach is based on generating
XHTML plus RDFa [
The data on the EDGAR program is public. Anyone can access and download this information for free. Consequently, once mapped to RDF, it can be integrated into the Web of Linked Open Data.
In order to connect the EDGAR dataset with other ones in the Web of Linked Data, the entities in the XBRL model have been analyzed in order to detect those also described in other datasets. The more prominent and interesting ones are companies, a kind of EntityType present in most EDGAR filings.
XBRL data provides an identifier for these entities, the Central Index Key (CIK) number. It is a number given to an individual or company by the U.S. SEC and used to identify the filings of a company, person, or entity in several online databases, including EDGAR.
However, there are some EDGAR filings that do not use this identifier and use the “CompanyName” one instead. For most of them it is possible to get the corresponding CIK using EDGAR’s CIK Lookup service7. Unfortunately, as the filings are directly submitted by the participant companies, there are some discrepancies between the names in the filings and those in the lookup service. For these, we are still trying to find some algorithm that allows us to relax the query when no results are returned or choose the appropriate one when more than one company is returned. In any case, we can get the appropriate CIK for most of the EDGAR filings.
Even when a CIK identifier is available, it might be impossible to directly connect it to company descriptions available in DBPedia because just some of them have the “secCik” property that links them to the company CIK. Due to these inconveniences, we have been able to directly link just 20 of the companies in the EDGAR dataset to DBPedia. Our work concentrates now on using the CIK Lookup service in order to obtain these identifiers for the DBPedia counterparts. 7 Search EDGAR: CIK Lookup, http://sec.gov/edgar/searchedgar/cik.htm
The XSD2OWL and XML2RDF mappings have been validated in different ways. First, we have used OWL validators in order to check the consistency of the resulting ontologies. Once all the ontologies were validated, which also includes checking that all the dependencies among them are met, we proceeded to put them into practice, together with the semantic metadata generated by the XML2RDF mapping.
In parallel with our efforts, the ontologies we have generated for XBRL using the XSD2OWL mapping have being also used by OpenLink Software in their XBRL sponge that translates XBRL to RDF. Apart from an independent evaluation of the ontologies, their reuse in the XBRL sponge also facilitates comparing the RDF data it generates with that resulting from the XML2RDF mapping we propose.
First of all, there is a significant difference in the number of triples generated by the OpenLink XBRL sponge and XML2RDF. For instance, for the same EDGAR XBRL filing 8, the XBRL sponge produces 900 triples while XML2RDF produces 4739 triples. One possible reason for this difference is that we have followed quite different approaches relative to how the original XML tree structure is captured in the RDF graph.
For instance, Table 1 shows in the first row a portion of XBRL XML instance data from the previous filing. The second row contains the RDF generated by the OpenLink sponge. As it can be seen, not all the information in the XBRL is captured and the whole structure is flattened.
On the other hand, the “c.)” row in Table 1 shows the mapping for the same XBRL XML as generated by the XML2RDF mapping. As it can be seen, the result is much move verbose, even more than the original XBRL. However, it does capture all the original information and keeps the original structure. Even more, the original XBRL does not explicitly refer to the XML Schema complexTypes defined in the schemas and used in the instance data. This information is available in the XML2RDF semantic data and can be used, together with the hierarchical relations among complex types, when resolving semantic queries against this data.
As it has been shown, it is possible to map the XML data for XBRL filings in order to generate RDF semantic data that keeps all the original information and structure. This mapping also includes the involved XML Schemas that structure the XML data, which are mapped to Web ontologies.
This approach has been put into practice in the context of the SEC’s EDGAR program that promotes XBRL filings for USA companies. It has been possible to apply the previous XML to RDF and XML Schema to Web ontology mappings to all the EDGAR filings and more than 1 million triples have been obtained.
Our approach has been partially adopted by OpenLink Software, a company that is currently using our XBRL ontologies in its own XBRL to RDF mapping product. However, OpenLink does not follow the same XML to RDF mapping approach. Their approach has been compared to ours showing that our proposal retains much more of the original XBRL information and structure. We have also have made all this semantic information generated from the EDGAR program available online, so it can be queried and browsed using a Web user interface. The proposed semantic queries illustrate the benefits of the semantic integration available once XBRL data is translated to semantic data.
Our work concentrates now on linking the resulting semantic data to the rest of the Web of Linked Open Data, completing the links to companies in DBPedia. Moreover, we are considering restructuring the semantic model resulting from mapping the XBRL XML because it is not intuitive and usable enough from a Semantic Web point of view. For instance, in the current model resulting from directly mapping from XML to RDF, Facts are modeled as properties while it would be more intuitive and easier to query if modeled as resources.