Not only. You can invalidate a table explicitly. If your incremental tabled program depends on some external database you can invalidate the table(s) that directly depend on the database. If you can somehow get a trigger that the database changed, it all works automatically.
Incremental shared tabling works in SWI. It is not yet extensively tested though, so I would not rely on it for production usage. One reason is that for most of the tabling XSB provided a rich set of tests, but this is novel ground, so we have to roll our own tests. If anyone has an interesting application for shared incremental tabling, please step forward and see how we can cooperate. This actually also applies for shared tabling alone as this never became really stable in XSB and thus (again) there are is no good test suite.
Sure. So far the only real-world test for incremental tabling is pharos. The SWI port is not yet integrated. It was unexpectedly simple to port and ran without issues right away after adding the necessary XSB library and built-in emulation. Since than some work was done on improving pharos and SWI-Prolog’s incremental tabling. It now also outperforms XSB on most of the pharos tests.
The analysis is not yet complete. XSB tabling is surely faster than SWI. It seems SWI’s tabling is starting to get fairly reliable though and SWI seems to outperform XSB on dealing with many dynamic predicates that have a lot of indexing requirements. The good news is that it does this without any indexing declarations while the XSB version is driven by indexing declarations.
Charles, thanks. Only the types (asset, liability, etc.) are hard-coded, not the accounts. Accounts can be added and updated using the user interface.
I had no idea that XBRL can encode or contain chart of accounts. But indeed it seems to be a one of the main concepts of XBRL and the extensibility of XBRL comes from ability to add custom accounts. I think that if I could associate each account with XBRL concept, then indeed I could automatically produce statements in XBRL format!
There is no closing or opening. You just don’t use multi-year aggregates and just add opening entries manually at the beginning of each year based on your last year annual report This is a tradeoff of simplicity versus convenience.
Estonia has two accounting standards, RTJ and IFRS. IFRS is like the actual standard, also used elsewhere, RTJ is more like a set of guidelines concerning mostly special cases like biological assets. Everything else is just based on barebones double-entry accounting. There is no standard chart of accounts, some companies manage with using just those 5 accounts presented in the accounting formula and an Excel worksheet.
Estonia has no corporate income tax, or income tax benefits. This just makes lots of different income reports unnecessary. This is a pretty unique system in the world but it makes lots of reporting much easier, especially for small companies. From me, they don’t even ask for a cash flow report anymore.
This is a stark contrast from Soviet times (ended in Estonia about 1991) where accounting rules were much more strict and unified to support the planned economy. There were even strict rules how many accountants each organization, factory or plant had to have. If soviets had been able to produce more computers (which they failed due to planned, not demand-based economy) they would have likely been the first to do large-scale standards-based automation of financial reporting.
It seems like integration with docstore would be nearly trivial by declaring docstore:eav/3 as incrementral(true). The question is whether this is useful, since every modification of the database would trigger it.
That is also the case for dynamic predicates. Dependent tabling goals are not re-evaluated though. They are merely flagged as needing reevaluation. If you call one of the invalid tabled predicates it will re-evaluate the table. It does so starting from the dependent tables closest to the dynamic predicate(s). If a table re-evaluates to the same set of answers it re-validates dependent tables (if they only depend on this table). I.e., the re-evaluation is lazy. The system recomputes entire tables though (where it is surely sometimes possible to merely propagate a new fact). This is all pretty much the same as in XSB.
For more information on Standard Business Report Model (SBRM). (SBRM is still a work in progress but you can see where this is going. This is about a logical conceptualization of a business report (including financial reports), not about the XBRL syntax or any other specific syntax. If ZERO regulators used XBRL, the logical model of a business report would still be incredibly useful. Think semantic spreadsheet.
This is a tradeoff of simplicity versus convenience.