[Biojava-l] object repository
Fri, 5 May 2000 13:48:26 -0700 (PDT)
> > Of course, this isn't a reason for not developing
> > persistance mechanisms for the cases where they're
> > > You didn't discuss using XML representations of
biojava objects. That
> > > might offer a reasonable way to allow a wide
variety of types of user to
> > > exploit biojava. Once you have the XML you can
do what you like with it...
> > XML is probably my preferred method for a lot of
> > persistance functions. BioJava is already using
XML a little bit:
> > take a look at the XmlMarkovModel class. I expect
this will grow,
> > but when there isn't an existing XML grammer which
> > requirements of a particular BioJava object, a bit
of care is needed
> > to create a new grammer which will be widely
> Regardless of all the niceties of XML, DTDs and
handling DOMs from Java,
> we have to face the fact that XML is in essence just
another way of
> defining flat file formats - fancy, easy-to-use file
> but flat files nevertheless. As such, an XML
representation of an object
> graph suffers from many of the same drawbacks that
other flat file
> representations suffer from (especially in contrast
to a database
> representation of the same object graph): no
datatypes (everything is a
> string); no transaction safety (isolation of
access); no query
> capabilities against the data; ...
ACtually, I'm working on some code which should, in
time, be able to store an xml document in a relational
database and provide transaction safety and
queryability, at least eventually. It remains to be
seen what the performance will be like, but I think
it'll be ok. Initially, I'm writing it in python, but
it works by sending xml documents to a url, so really
it's language independant. It could be easily ported
to java, however, and be given an api.
> Additionally, XML representations tend to be verbous
- so you need to
> compress on the fly.
>This can be a serious limitation, especially if you
are only interested in
>one piece of information buried in a huge xml
I think it'll be easy to grab doc fragments (in my
database thing I was talking about, that is). There's
no need to call up an entire xml document to get a
> All this makes XML IMHO a very nice vehicle for the
> platform-neutral representation of data (e.g. for
> import/export) but makes the idea of building a
datastore of objects in
> XML not really much more attractive than it would be
in any other flat
> file format.
I don't agree with that. While an xml db approach
isn't as nice as a direct db translation, it is
certainly superior to other flat formats in terms of
queryability and granularity.
One last point in xml's favor is that xsl is a very
nice way to convert between xml formats - without
programming even, so that changes in schema's/data
structures can be handled easily.
PS I don't know if this has been mentioned, but there
are at least two open source pure java odbms's. One
is at www.jdbms.org and the other is www.ozone-db.org
.. ozone also has some built-in xml support, although
the last I knew it was still pretty slow (months ago).
These might be useful for small-medium sized data
repositories. They're very easy to use.
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.