shared API for double-entry accounting, treating it as a 'math' library.

HRJet hrjet9 at gmail.com
Thu Nov 14 14:23:52 EST 2013


To me, the XML format is just a technical detail. The end-user format could
be anything (JSON included). I was more interested in the concepts behind
RDF.

The core concept is to formalise a method to declare logical facts and
rules. And then tools can be built upon this, that can infer facts
automatically.  Say, for example, if you declare the following facts:

1. John is a man
2. All men are animals
3. All animals eat food

>From these you can infer that John eats food. You can also query the
system: "what operation does John do with food?" or "gimme a list of all
animals". If you are familiar with Prolog / Datalog, this will sound very
natural.

Now, let's take a more relevant example. Consider a set of the following
facts:
1. John paid me 2000 USD in cash on 15 November 2013.
2. All those who pay me money are my customers.
3. All customers who pay me more than 1000 USD in a month are high-value
customers.

>From this, it can be inferred that John is a high value customer!

RDF allows the expressions of these facts and rules in a standard way.
Other related standards allow the expression of queries. It's a very mature
ecosystem.

The biggest advantage of such a system would be, you won't need to program
a system every time you need some customisation. If you want to record
something unique in your work-flow, you can just add that fact to the
system.

Say you want to add a rule that, every transactions should be < 1 million
USD. Just add that rule, and bing! The system will check all facts, and
warn you of inconsistencies. Want to record the location of a transaction?
Add it as a fact by itself, and you are done. No need to worry about the
schema. Want to deduce the location of customers from their transaction?
Just a rule and query away.

You could call the system of rules and queries as a form of programming,
and it is; just a more declarative form of programming which is less prone
to errors and very open to customisations (yet avoiding inconsistent
interpretation).

Now the real deal is this: The standardisation effort can be at the level
of rules. One could prescribe a set of rules and facts as a standard for
accounting. This would be the "API"; though a very high level one. Having
such a ready made system of rules will help anyone to quickly adopt the
system, and to interoperate with other RDF instances (say an RDF system for
inventory).

Take all this with a pinch of salt; I don't have actual experience with
RDF. There might be practical hurdles. But I hope I have conveyed the
potential of this approach.

best,
-- 
HRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20131115/25a5444b/attachment.html>


More information about the npo-accounting mailing list