<div dir="ltr"><div class="gmail_default" style="font-size:small">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.<br>


<br></div><div class="gmail_default" style="font-size:small">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:<br>


<br></div><div class="gmail_default" style="font-size:small">1. John is a man<br></div><div class="gmail_default" style="font-size:small">2. All men are animals<br></div><div class="gmail_default" style="font-size:small">


3. All animals eat food<br><br></div><div class="gmail_default" style="font-size:small">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.<br>


<br></div><div class="gmail_default" style="font-size:small">Now, let's take a more relevant example. Consider a set of the following facts:<br></div><div class="gmail_default" style="font-size:small">1. John paid me 2000 USD in cash on 15 November 2013.<br>


</div><div class="gmail_default" style="font-size:small">2. All those who pay me money are my customers.<br></div><div class="gmail_default" style="font-size:small">3. All customers who pay me more than 1000 USD in a month are high-value customers.<br>


<br>From this, it can be inferred that John is a high value customer!<br><br></div><div class="gmail_default" style="font-size:small">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.<br>


<br></div><div class="gmail_default" style="font-size:small">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.<br>


<br>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.<br>


<br></div><div class="gmail_default" style="font-size:small">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).<br>


<br></div><div class="gmail_default" style="font-size:small">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).<br>


</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.<br>


</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">best,<br></div><div class="gmail_default" style="font-size:small">-- <br></div><div class="gmail_default" style="font-size:small">


HRJ<br></div></div>