<div class="notebook"> <div class="nb-cell markdown" name="md6"> ### About caching To avoid long waits while this server requests XBRL resources from their remote servers, those are cached. The current policy is to always use the cached version if it was obtained during the last: ```eval :-xbrl:defaultCacheValidity(Seconds), Minutes is Seconds/60, format(" *~w minutes*",[Minutes]). ``` Otherwise, the resource is fetched from the source over the web *IF* it has changed. This should work for most people, but if you happen to be quicky changing those XBRL resources in parallel with what you're doing here, you can invalidate (delete) the cache with a brutal xbrl:clearCache. You may also peek at the current contents of the cache: xbrl:printCache. Notice that the cache is shared by all users, so be gentle; the above primitives will likely become restricted in a later version. </div> <div class="nb-cell markdown" name="md2"> ### About sessions A HTTP session has an associated internal storage, where one or more reports can be loaded. Typically one session per user browser. The server has a limit on the number of sessions, and once reached no more requests can be made. Sessions have a standard timeout, so they get cleared when not used for a while. But for the impacient, it is possible to kill all current sessions: webapi:closeAllSessions. </div> <div class="nb-cell markdown" name="md5"> ### Why PROLOG ? XBRL's primary representation is in XML and related standards. Although XSLTs and XPATH may be regarded by some as a "programming language", it's convenient to use instead a real programming language, friendlier and much more powerful; so over time people have naturally evolved a bunch of XBRL toolkits, starting with Java and other languages. So the challenge came up Spring 2020: as people start moving beyond standard XBRL into higher level reporting concepts and patterns, with a subjacent logical vision towards report consistency etc, might we (http://logicalcontracts.com) have something to say? PROLOG fits particularly well this challenge, because it provides "out of the box" (in addition to the ISO PROLOG standard core) a number of key features: * Relational paradigm addresses tabular data (e.g. RDBMS) while optimised support for recursive code addresses tree and graph data (e.g. graph DBs, RDF) * Basic logic engine already built-in * Extensive meta programming capabilities, handy for formula evaluation * Flexible parser, facilitating friendlier syntaxes * Builtin search and tree matching * Very efficient C-based engine, with RAM usage an order of magnitude under the alternatives * Vast open source API libraries, including XML and semantic web processing processing * Mature [implementation](https://www.swi-prolog.org/), consolidating over 3 decades of optimisation and refinement in the fields of Logic Programming and Cognitive AI. * [Recent features](https://www.swi-prolog.org/download/publications/swi7.pdf) for smoothier integration with other languages and to build Domain Specific Languages, such as [our own](https://arxiv.org/abs/1808.08042). You can find a more compreensive list of PROLOG advantages [here](https://www.swi-prolog.org/features.html), and a related business view perspective [there](http://xbrl.squarespace.com/journal/2020/8/9/business-case-for-modern-prolog.html). Some additional impressions from our recent experience applying PROLOG and logic programming know how: * The Toolkit started with the conversion of XBRL instances and their full DTS into a compact Prolog representation; the above XBRL user formula (which happen to be a single Prolog clause) should make this point clear. * Formula evaluation, including variable binding, is done by the straight execution of a Prolog goal (actually, a reasoning derivation) generated from the formula; this follows naturally from accumulated know-how in meta interpreters and partial evaluation * The value cell coloring above, namely the green - meaning "this is covered by some assertion" - is a simple application of a standard PROLOG technique for generating reasoning explanations * XPath and Prolog search combined navigate the XBRL documents, which Prolog relations accumulate an equivalent but more amenable representation, ready to fuel reasoning upon it. * Declarative descriptions of (say) concept arrangement patterns map to declarative PROLOG clauses. After this first step, now upper layers (model patterns, more complex rules) can be added. </div> <div class="nb-cell markdown" name="md1"> ### XBRL represented in PROLOG As an example, you can see [here](example/PROOF.pl) the result of loading the PROOF report instance and its taxonomy set. Some comments: - Each Prolog relation is headed by a comment with a terse argument description; names are mostly aligned to XBRL concepts. The first argument is always the report instance URL. - fact_precise_ is a redundant relation, obtained from fact_ and retaining only the most precise representation - complexType contains XML Schema type definitions, only partialy groked by Pacioli, which keeps a XMl "blob" in its last argument - formula_ keeps formulas as Prolog expressions ('rule' argument) bound to variables and their filters - ruleOutcome has the result of report validation by the rules, including the facts supporting the outcome in the second argument (inconsistent, consistent, not evaluated) - cached_fact is... a cache of facts together with the concept arrangement terms they belong to, labels etc _ the sbrm_XXX relations contain the SBRM representation of the report above Further documentation forthcoming. </div> </div>