Tom Tuddenham wrote:
> Hi folks
>
> Standard qualifier for probably not understanding what's going on, but isn't
> XML persistence slightly orthogonal to managing Archetypes? I mean to say,
> persistence is important but can't it be deferred to a systems that already
> offer XML native based persistence, e.g.
> http://www.sleepycat.com/products/bdbxml.html or one of the existing
> XML-to-RDBMS mapping solutions.
>
> Again, I may misunderstand what you're trying to achieve, but won't storing
> serialized data in the second column make for potentially complex queries,
> especially if you're doing keyword searches. I'm undoubtedly showing my
> cluelessness here - but wouldn't an XQuery based interrogation of the
> repository work be more applicable than SQL?
>
none of this is clueless, don't worry. In fact you have hit several
nails on the head. I am in the middle of writing an FAQ on all this
still which I will try and get up in the next few days. In summary:
* persisting openEHR data structures e.g. Compositions etc is no
different from persisting any other typically fine-grained
hierarchical / object data
* so you can do normal analysis on it; you can store serilialised
data blobs, and queries do then have to be thought about more
carefully; but the other side of the coin is that not every
fine-grained node needs tobe directly queryable....
* except for one little exception - due to being archetyped, the
data is full of node ids and hence every node is guaranteed to be
addressable with an Xpath-style path (we do a couple of
machine-processable shortcuts on our paths to reduce the length,
but otherwise they are Xpaths - see the section on Paths in
http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview.pdf.
So one very interesting option for storing the data is as <path,
serialised node> pairs, which is dead easy in a relational
database, and is very queryable, due to the paths being
semantically meaningful (due to being defined by archetypes).
What I aim to do is to just put up an initial FAQ; there is no doubt a
lot of expertise in object and O/R persistence here in the community,
and I would like to get others to contribute their knowledge as well
(without trying to write just a general purpose lesson on O/R
persistence - there are many of those already available).
(Probably we should set up a wiki at some point....)
- thomas
