Multiple Facts, same Name

Jan 1, 2013 at 2:25 AM
Edited Jan 1, 2013 at 2:27 AM

Gepsio is working out a lot better for me in understanding and digesting XBRL! Which is awesome!

I just have a question getting started, I've taken a recent AAPL 10-K and downloaded it and started to look through it.

I understand from looking through the documentation that XbrlFragment contains multiple Facts which could be either an Item or a Tuple

In my first go-round, I just output all the facts cast as Items

      foreach (XbrlFragment fragment in Doc.XbrlFragments)
      	Console.WriteLine("Facts in fragments: "+fragment.Facts);                   
	foreach(Item fact in fragment.Facts){
        	Console.WriteLine("Name: " + fact.Name + " | Value: " + fact.Value.ToString());

However, this caused me to have multiple Facts elements with the same name, for example, StockHolderEquity comes up at elements 1,7,8 - etc., representing different parts of the same areas of the fact sheet (I'm new to XBRL) - but I able to gather these different values are actually different columns on the same line: like: Total, Common Stock (Value,Shares), Retrained Earnings, etc. 

Is this the concept of a tuple? If it is, or if it's not I am trying to understand a good way to figure out the specifics of what I'm looking at? Do I need to associate each Fact with it's Context to figure out what it is? And if it's a calculation of other fields, or a component of another Fact?

Jan 23, 2013 at 6:29 AM

Still haven't been able to figure out how to interpret the relationships between these different values. I understand that there is a 'calculation link' between different facts, but I don't know how to discover this within Gepsio?

The CalculationArc class seems to be where I would look for this information, but when targeting a base XBRL document as in my example, I don't know how to load the Calculation link base to discover the relationships between facts.

Jan 23, 2013 at 1:12 PM

If you look down a few topics chronologically you'll see that my ("NEWB") problems are very similar.  For starters,  you'll find that each fact has an associated temporal context ("instant" in time or period in time).  If you're lucky that will allow you to sort out your multiple-value problem.  If not, you've a problem similar to mine.  Jeff indicated a couple of months ago, but he hasn't been heard from since.

The "father" of XBRL recommended to me on the XBRL general forum that I chase the calculation chain to deduce which fact I wanted.  I replied that I didn't think that was worth the bother.  Personally, I concluded, right or wrong, that companies were plunging down the road tagging their data, and, when they run into weaknesses in the XBRL or other related standards, they adopt their own ad hoc conventions (e.g., distinguishing context names).  I was dealing with IBM data, and there was a different context name for each (fact, context).  That worked fine enough for IBM, but others tag differently.

Jan 23, 2013 at 1:38 PM

Thanks for the feedback! I am here, and I apologize for my delay in responding to you.

Are you using the most recent AAPL 10-K? I want to address the issue by looking at the same filing you are. If you'd care to attach the XBRL instance document and associated schemas and linkbase documents, I will be able to follow along with your work.

I think Walt makes a good point regarding the inconsistency of XBRL instance authors. I will take a look at how much Gepsio can do to combat this inconsistency.

Jan 23, 2013 at 3:29 PM
Edited Jan 23, 2013 at 3:30 PM

Hey guys!

@JeffreyFerguson - yes, most recent before today (as they are filing again later today Jan. 23, 2013)

Thanks for getting back to me. SO I think at least part of my issue (as I discovered after posting last night) was that I don't think I was getting the associated Cal. link-base document. I know that the latest Gepsio includes a URL based link-base associated document download, but I don't know if this was happening when I referenced the document remotely as I did in my example. 

When I downloaded all the files and placed the base document in a local directory with the associated linkbase documents in the same folder I started to get more information (cal. orders, weights, to-from, etc.)

I know it's going to be kind of a chore, but I think what I need to do next is write a method to try to follow this order of ops (trying to get closer to creating a view more like the XBRL Previewer on the SEC's website)


Fragment Facts -> Look for Schema association (as WaltN mentions) -> Look for calculation link and order (within the schema?) -> Organize -> Store


I don't know if i can attach a file directly on codeplex -- here is a link to the document's view on the SEC website:

Jan 25, 2013 at 3:14 PM

Thanks for the link! I'll be looking at this filing over the weekend.

Can you tell me more about what you're trying to do, exactly? From what I can surmise, you have StockHolderEquity facts, and you're trying to figure out how to find the values for the columns in that row, such as Total, Common Stock (Value,Shares), and Retrained Earnings. Is that correct? If it isn't, please correct me.

If this is hard to do in raw XBRL, and Gepsio has enough information to figure it out, then it seems to be that Gepsio should be providing additional methods and properties to make finding this information easier. After all, that's my vision for Gepsio: make XBRL easier.

Jan 25, 2013 at 3:25 PM
Edited Jan 25, 2013 at 3:27 PM


Your correct. Thanks for looking over it. I spent some more time last night trying to build up data-structures for items like, for example, "Consolidated Statement of Shareholders Equity", which is the item I initially had in question (just because it was the first fact pulled out).

So I tried taking the fact name, for example: "us_gaap-StockHoldersEquity" but since that tag is re-used it's hard to find the association between that particular tag and it's let's call it "parent" table like CSOSE

Jan 25, 2013 at 3:33 PM

Oh, OK. Thanks for the clarification. I will take a look at it this weekend. I am going to presume that all of the necessary ties are in the XBRL document. If that is true, then Gepsio has access to them. If that is true, the Gepsio needs to do a better job of pulling them out for your inspection.

I'll post more info when I have it, and may be writing a blog post to address the issue and Gepsio's solution to the problem.

Thanks for helping me make Gepsio better and more useful!

Feb 15, 2013 at 7:51 PM
Hey Jeff, have you had a chance to look at this yet?