The Gnucash database?

[Josh Sled]

On Tue, 2004-07-27 at 07:21, Mark H. Wood wrote:

> > > I don't see why it is *impossible* to load CSV data into Gnucash.
> >
> > Its not impossible, its just that one needs to write a GUI to
> > describe the data format to gnucash; how to map the various columns
> > of this flat file to thier gnucash equivalents.
> 
> It seems that we agree, more or less.  Of course the user must supply a
> mapping from one application's terms to the other.  It doesn't have to be
> done GUI-style, though; it could be supplied in (drum roll) another file.

Yes.  One could imagine the QIF and OFX importers being expressed in a
declarative manner.  It's pretty hard to see a clear path to the
implementation of that, however...

In the mean time [:)] we'd be happy to accept the code that allows the
user to map CVS columns into gnucash concepts.


> A common standard for exchange of financial data would be useful.  I don't
> see how RDBMSs have anything to do with that, though.

Yes.  In some respect, the most appropriate particular choice of tables
[the realization of data model] is going to be a function of the context
in which those tables are utilized.  A commmon data-model that suits all
applications is probably possible, but impractical.

But as an exchange mechanism -- things like OFX and QIF [modulo it's own
problems] are very good indeed.


> With respect to accounting and bookkeeping, an RDBMS improves upon paper
> records by making it easy to view the same heap of records in many
> different ways.  One of the problems with paper is that, once you've
> written, that's that.  Rearranging and filtering are possible on paper
> only by copying.  Stuff the data into a database, though, and you can ask
> for subsets, sorted and grouped to order, without the problems inherent in
> the maintenance of duplicated data.

Another way of saying this is that expressing the relations between data
[within a generic relational algebra] is a wonderful mechanism for doing
a lot of practical things that people want to do, such as query,
intersect sets, &c.


> This doesn't help a lot with exchange, though.  The common language for
> accounting metadata is still missing.  At most one can achieve, not a
> universal exchange, but a bunch of bilateral agreements about exchange.

You're exactly correct.  It's all about the semantics [not the syntax]
-- and moreover on the _agreement_ on both the syntax and semantics. 
XML has resonated very well with a lot of people because they thought it
would help solve this; unfortunately it turns out that it's primarily a
_syntactic_ agreement -- it defines a particular way of writing
structured information, but not enough of a framework to enable the
interelation of meaning.

[FWIW... RDF [1] is increasingly ... interesting ... to many people
since:
a/ it specifically addresses semantics primarily, and syntax 
   secondarily.
b/ it does have a proscribed XML representation.
c/ it has easier-to-use representations [2] that are _not_ XML  :)
d/ it inherently represents graphs, not simply trees.
e/ the framework it represents supports the _sharing_ of 
   properties, rather than the redefinition that XML 
   encourages.
]


But the key problems remain:
* what is a "transaction"?
* how do we identify an "account"?  name it?  type it?
* how do we represent commodity/currency and monetary amounts?


> The various EDI standards have nibbled at this problem, although
> accounting is not the only thing they're aimed at.

Yeah, that's been the problem I've seen in looking for existing
standards in this area -- they're all about "bigger" things, which make
it seem like a lot of baggage is going to need to be pulled in.  If
anyone has seen anything simple that would be a reasonable interchange
format for GnuCash data please let us know.  Otherwise, we'll have to
define it later ...

... but only after the gnome2 port is done. :)

...jsled

[1]: http://www.w3.org/RDF/
[2]: http://www.ilrt.bris.ac.uk/discovery/2004/01/turtle/

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`