How to identify period end contexts in xbrl filings? - xbrl

I am trying to find only the current period concepts and facts for the three main financial statements. The goal is to be able to iterate through filings of different companies in different periods.
Using Ebay 2017 10-k as an example.
For concepts that capture YoY change, like those in income statement and statement of cash flows, I can use context found in any of the dei tags, for example:
<dei:DocumentFiscalYearFocus contextRef="FD2017Q4YTD" id="Fact-2E3E1FD4D81352F693510AE035FDC862-wk-Fact-2E3E1FD4D81352F693510AE035FDC862">2017</dei:DocumentFiscalYearFocus>
dei:DocumentFiscalYearFocus tag is required, and its context "FD2017Q4YTD" is also found in all IS and SCF period end concepts, so that's easy.
However, balance sheet concepts use a different context:
<us-gaap:CashAndCashEquivalentsAtCarryingValue contextRef="FI2017Q4" decimals="-6" id="d15135667e874-wk-Fact-3E4A0A2B272B59DE9DAF004097ECF968" unitRef="usd">2120000000</us-gaap:CashAndCashEquivalentsAtCarryingValue>
Any idea how to identify the "FI2017Q4" context (or otherwise find current period balance sheet concepts)?

The XBRL document instance you are viewing contains one or more schemaRef elements, each of which loads an XBRL taxonomy, or data dictionary, for the XBRL instance. Somewhere, within that reference graph of files (and there could be several files), is the definition of each context. The definition will look something like this:
<context id="CONTEXT_ID_NAME">
<!-- ... child elements appear here ... -->
</context>
If you can find the <context> element with an attribute of id that matches the contextRef you're interested in, then you've found what you're looking for. In your case, you're looking in the related XBRL taxonomy files for something that says <context ID="FD2017Q4YTD"> and <context ID="FI2017Q4">.
The child elements of the <context> element describes the dates for the context. There are two types of XBRL contexts:
instant, which specifies a context with a single date
period, which specifies a context with a start date and an end date
The child elements of the <context> element will describe which type of context being described.
This work is all manually doable, but it might be best to use XBRL processing software, which will perform all of this work for you.

The value of the contextRef attribute is purely an identifier that references a context definition elsewhere in the document. Using the eBay example, you'll find this context definition:
<context id="FI2017Q4">
<entity>
<identifier scheme="http://www.sec.gov/CIK">0001065088</identifier>
</entity>
<period>
<instant>2017-12-31</instant>
</period>
</context>
The value in the "instant" element is what tells you what date facts associated with this context relate to.
In order to properly understand the XBRL facts, you need to fully understand the associated contexts. There may be other information, such as additional dimensions, defined here.
I'd strongly recommend working with an existing XBRL processor that will resolve the contextual information for you, such as the open source Arelle processor, or the API provided by XBRL US.
One possible approach to working with XBRL data is to use a processor that converts data to the newer xBRL-JSON format, which provides fact objects with all contextual information fully resolved.

Related

Dropdown should to be populated by the document values not the document name

as you may be able to see from my image below, my drop-down is populated by the display name not the value from the table bindings. Did I miss something or did I get the Document definition wrong?
<association type="aggregation" name="noteType">
<displayName>NoteType</displayName>
<documentName>NoteType</documentName>
</association>
is it missing something to tell it to use the binding?
Any assistance would be greatly appreciated.
good question.
In the situation where you are associating an object instance from another object instance (in this case perhaps from a Note to a NoteType), the default widget Skyve will propose for the view will be a lookupDescription (the drop down in your screenshot). NoteType is a document which may have many attributes - the lookupDescription widget has a descriptionBinding - this is usually set to bizKey but can also be set directly to one of the attributes of NoteType. The bizKey in a document defaults to be the same as the document's singular alias until you set it, resulting in what you see above.
Take for example that NoteType has 3 attributes, an code (text), a typeName (text) and a description (memo).
e.g., Note Types:
code
typeName
description
NWS
news
a news item for the team
ALT
alert
an urgent alert
COM
comment
a general comment
RAN
random
a fun item not related to work
in this case it is not obvious what to show in the drop down or lookupDescription. Perhaps you may want to use the code attribute ("NWS", "ALT" ...) or the typeName attribute (e.g. "news", "alert" ... ) in the drop down, or a mashup of several of the attributes of NoteType like typeName and code (e.g. "NWS (news)", "ALT (alert)" ...).
Whereas in Java you can specify a .toString() method, in Skyve you specify a bizKey - see https://skyvers.github.io/skyve-dev-guide/documents/#bizkey.
For this example, I could specify the NoteType document bizKey attribute like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<document name="NoteType" ...>
<persistent name="NoteType"/>
<singularAlias>Note Type</singularAlias>
<pluralAlias>Note Types</pluralAlias>
<bizKey expression="{code} ({name})" />
<attributes>
<text name="code" >
<displayName>Code</displayName>
<length>3</length>
</text>
<text name="typeName" >
<displayName>Type Name</displayName>
<length>50</length>
</text>
<memo name="description" >
<displayName>Description</displayName>
</memo>
</attributes>
</document>
where bizKey has the expression "{code} ({name})" yielding "NWS (news)", "ALT (alert)" ... this uses Skyve expressions which will be re-evaluated as part of the bean lifecycle and saved as the special database field bizKey.
You can also define the bizKey in Java - for an example of this, check the Contact document (Contact.xml file) in the admin module in your project.
The bizKey attribute is required by Skyve - so when you create a project in Skyve Foundry, the bizKey attribute in the project xml is generated to default to the singular alias (or document name) - in your case "NoteType" to make sure it will have a value.
The bizKey is required by Skyve so that there is always a way for the application to refer to an instance of a document. This is especially important for no-code situations where the developer may not yet have got around to specifying things precisely but wants to be able to start to use the application as a proof of concept.
The bizKey attribute is persisted (saved) in the database for performance reasons - so that Skyve can rapidly retrieve and filter rows based on bizKey values, rather than attempting to calculate them as a derived expression (which would require conversion of expressions or Java code to dialect-specific SQL and also add extra processing every time bizKey values were retrieved).
This means that if you have created data with a different bizKey definition, you'll need to resave your NoteType records. You can do this easily by:
signing in to your Skyve application as an administrator (or the setup/bootstrap user if you have one)
navigate to admin->Devops->Data Maintenance and choose the Data Refresh tab
select the NoteType document, choose the Option "Save" and press "Refresh Persisted Document Data"
For reference:
https://skyvers.github.io/skyve-dev-guide/documents/#documentxml-sections
https://skyvers.github.io/skyve-dev-guide/expressions/
https://skyvers.github.io/skyve-dev-guide/skyve-persistence-mechanisms/

Why while querying ontologies we have to load the ontology, also provide its namespace?

I wonder why we have to load an ontology, also provide its namespace while querying it? Why loading the ontology is not enough?
To understand my question better, here is a sample code:
g = rdflib.Graph()
g.parse('ppp.owl', format='turtle')
ppp = rdflib.Namespace('http://purl.org/xxx/ont/ppp/')
g.bind('ppp', ppp)
In line 2, we have opened the ontology (ppp.owl), but in line 3 we also provided its namespace. Does namespace show the program how to handle the ontology?
Cheers,
RF
To specify an element over the semantic web you need its URI: Unique Resource Identifier, which is composed of the namespace and the localname. For example, consider Person an RDF class; how would you differentiate the Person DBpedia class http://dbpedia.org/ontology/Person from Person in some other ontology somewhere? you need the namespace http://dbpedia.org/ontology/ and the local name Person. Which both uniquely identify the class.
Now coming back to your specific question, when you query the ontology, you might use multiple namespaces, some namespaces may not be the one of your ontology. You need other namespaces for querying your own ontology, e.g. rdf, rdfs, and owl. As an example, you can rarely write an arbitrary query without rdf:type property, which is included under the rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns> namespace, not your ontology namespace. As a consequence, you need to specify the namespace.
Well, now as you should know why to use a namespace, then we can proceed. Why to repeat the whole string of the namespace each time it is needed? It is nothing more than a prefix string appended to the local names to use in the query, to avoid writing exhaustively the full uri. See the difference between <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> and type.
Edit
As #AKSW says, as a conclusion, there is no need to declare a namespace in order to work with the ontology but it increases the convenience when working quite often with resources whose URI has particular namespace.

Processing presentation from XBRL taxonomy

I'm trying to parse presentation files from XBRL taxonomy.
This is an extract from file where I have trouble:
<presentationLink xlink:type="extended" xlink:role="http://www.infocamere.it/itnn/fr/itcc/role/NotaIntegrativaAttivo">
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_AttivitaOperazioniLocazioneFinanziariaLocatario" xlink:to="itcc-ci_ContrattiCorsoOperazioniLocazioneFinanziariaLocatario" order="1" priority="0" use="optional"/>
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_ContrattiCorsoOperazioniLocazioneFinanziariaLocatario" xlink:to="itcc-ci_BeniLeasingFinanziario" order="1" preferredLabel="http://www.xbrl.org/2003/role/periodStartLabel" priority="0" use="optional"/>
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_BeniLeasingFinanziario" xlink:to="itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento" order="1" preferredLabel="http://www.xbrl.org/2003/role/periodStartLabel" priority="0" use="optional"/>
</presentationLink>
<presentationLink xlink:type="extended" xlink:role="http://www.infocamere.it/itnn/fr/itcc/role/NotaIntegrativaAttivo">
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_ContrattiCorsoOperazioniLocazioneFinanziariaLocatario" xlink:to="itcc-ci_BeniLeasingFinanziario" order="2" preferredLabel="http://www.xbrl.org/2003/role/periodEndLabel" priority="0" use="optional"/>
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_BeniLeasingFinanziario" xlink:to="itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento" order="1" preferredLabel="http://www.xbrl.org/2003/role/periodEndLabel" priority="0" use="optional"/>
</presentationLink>
The result should be
itcc-ci_AttivitaOperazioniLocazioneFinanziariaLocatario
itcc-ci_ContrattiCorsoOperazioniLocazioneFinanziariaLocatario
itcc-ci_BeniLeasingFinanziario (periodStartLabel, order=1)
itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento (periodStartLabel, order=1)
itcc-ci_BeniLeasingFinanziario (periodEndLabel, order=2)
itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento (periodEndLabel, order=1)
Is this the valid way to implements this hierarchy using presentationLink?
I have trouble identify parent node for 'itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento'.
Should I resolve parent for 'itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento' using presentationLinks as different containters and after merge presentationLinks to build the complete or I have only to scan every presentationArc and refer to last parent found?
I have read a lot of docs and code but I still have a doubts about how to solve this problem.
Thanks in advance to all for the answer.
I hope I was clear,English in not my native language.
You'll need to read the specifications. Neither of your suggestions are likely to result in the correct answer.
You need to work out the Network of Relationships for this relationship type and role. A very high level summary:
group the arcs into 'base sets' and find the one for this network
find the equivalent relationships
remove any prohibited or overridden relationships
You might get away without 2 & 3 if there aren't any. What you're left with is a bunch of relationships that describe this network which will allow you to build the tree.
If you have no idea what I'm talking about, then I'd strongly suggest using a 3rd party XBRL library. The specs aren't written in the most straightforward manner, and the fact English isn't your native language won't make this easier.

Same domain members present in multiple dimensions in XBRL taxonomy

While going through the definition link base of a taxonomy, i found that a few domain members were present in two separate dimensions. Eg. Dim A contains domain Dom1 with members m1, m2,m3,m4. And Dim B contains domain dom2 with members m2,m3,m4. The issue is that it may lead to conflicting context names (even though the segment part of the contexts will be different).
The format of the context name is 'periodInformation_domainMember'. I need to use different dimensions for different sections of my report. So my basic question is how do i form context names?
I hope i have conveyed myself properly.
Appreciate any help... :)
use "Period Information + Dimension + member name" for making context names unique.....
You have to check the uniqueness based on the child nodes of <period> tag and child nodes of the <segment> tag... here in segment; if segment is present then each xbrldi:explicitMember has dimension in its attribute and member in its value...
...more: http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-04-25.htm#_4.7
What if there were multiple dimensions? Playing devil's advocate, what if you have dimensions with the same local name but in different namespaces? The only way to guarantee a unique name is to use the whole content of the context - which is ridiculous.
I've seen recommendations by regulators requiring filings in XBRL that 'Semantics SHOULD NOT be expressed...' in a context id and it is '..recommended to keep it as short as possible...'
The simplest solution is to pick unique names that that have nothing to do with the contents - for example c-1, c-2 etc.
The syntax of the XBRL is unimportant, it's just an implementation detail.

IBM Websphere scripting ID 'containment paths' explained (I.e. AdminConfig.getid(...) )

I have been digging through IBM knowledge center and have returned frustrated at the lack of definition to some of their scripting interfaces.
IBM keeps talking about a containment path used in their id definitions and I am only assuming that it corresponds to an xml element within file in the websphere config folder hierachy, but that's only from observation. I haven't found this declared in any documentation as yet.
Also, to find an ID, there is a syntax that needs to be used that will retrieve it, yet I cannot find a reference to the possible values of 'types' used in the AdminConfig.getid(...) function call.
So to summarize I have a couple questions:
What is the correct definition of the id "heirachy" both for fetching an id and for the id itself?
e.g. to get an Id of the server I would say something like: AdminConfig.getid('/Cell:MYCOMPUTERNode01Cell/Node:MYCOMPUTERNode01/Server:server1'), which would give me an id something like: server1(cells/MYCOMPUTERNode01Cell/nodes/MYCOMPUTERNode01/servers/server1|server.xml#server_1873491723429)
What are the possible /type values in retrieving the id from the websphere server?
e.g. in the above example, /Cell, /Node and /Server are examples of type values used in queries.
UPDATE: I have discovered this document that outlines the locations of various configuration files in the configuration directory.
UPDATE: I am starting to think that the configuration files represent complex objects with attributes and nested attributes. not every object with an 'id' is query-able through the AdminConfig.getid(<containment_path>). Object attributes (and this is not attributes in the strict xml sense as 'attributes' could be nested nodes with a simple structure within the parent node) may be queried using AdminConfig.showAttribute(<element_id>, <attribute_name>). This function will either return the string value of the inline attribute of the element itself or a string list representation of the ids of the nested attribute node(s).
UPDATE: I have discovered the AdminConfig.types() function that will display a list of all manipulatible object types in the configuration files and the AdminConfig.parent() function that displays what nodes are considered parents of the specified node.
Note: The AdminConfig.parent() function does not reveal the parents in order of their hierachy, rather it seems to just present a list of parents. e.g. AdminConfig.parent('JDBCProvider') gives us this exact list: 'Cell\nDeployment\nNode\nServer\nServerCluster' and even though Server comes before ServerCluster , running AdminConfig.parent('Server') reveals it's parents as: 'Node\nServerCluster'. Although some elements can have no parents - e.g. Cell - Some elements produce an error when running the parent function - e.g. Deployment.
Due to the apparent lack of a reciprocal AdminConfig.children() function, It appears as though obtaining a full hierachical tree of parents/children lies in calling this function on each of the elements returned from the AdminConfig.parent(<>) call and combining the results. That being said, a trial and error approach is mostly fruitful due to the sometimes obvious ordering.