Re: Non-SQL Persistence for PL

Hi,

if there is a way of efficiently serialising and deserialising
only those objects which represent definitions and propositions
as you do it with your 'schema-less' RDBMS, that would surely
be a better approach than serialising the complete object graph.

When you say you use the RDBMS to store serialised objects in it,
does that mean that you have one single table with rows for each
proposition or definition? Or different tables for different
types of objects? And if I understand correctly, the caching/
paging is implemented in Stella on top of the RDBMS?

I would like to try either AllegroCache and/or other object 
persistence tools, so I looked into the code of the rdbms 
system and saw how you use demons and db-relation-goes-xxx 
functions and have a vague idea of what would be necessary.

The experimental code you mention, would be very interesting
as the rdbms code is still very close to the notion of
tables (deftable ...). I would appreciate even small code 
snippets or other information about the mechanism you use
to store propositions in a generic way.


Thank you.


Kambiz

----- Original Message -----
From: "Hans Chalupsky" <[email protected]>
To: [email protected]
Cc: "PowerLoom Forum" <[email protected]>
Sent: Donnerstag, 30. August 2007 0.00 Uhr (GMT+0100) Europe/Berlin
Subject: [PowerLoom Forum] Non-SQL Persistence for PL

Kambiz,

we do have an experimental version of persistence that doesn't require
you to have a DB schema, but that basically persists PowerLoom
definitions and propositions in a special-purpose "schema-less" RDBMS
database.  The system then pages those objects in on demand and uses
extensive caching to make things fast.  In a sense this is
implementing a type of persistent object system by serializing the
objects to an RDBMS.  The problem with this is that it isn't quite
complete.  We've loaded, persisted and queried large ontologies with
that, but there are a variety of loose ends that would make this
difficult for you to use at this point.

Several years ago we've played with some persistent object systems
(such as Versant and PLOB - a free version of persistent Lisp
objects), but the performance was never very satisfying.  That might
have changed by now with Allegro Cache, but I don't have any real data
on that.  The other issue is that a loaded PowerLoom module has a host
of PowerLoom and STELLA data structures associated with it that all
would need to be persisted, which means that you basically have to
make all object classes of STELLA and PowerLoom persistent to make things
work (without some major re-architecting).  I don't know how difficult
that would be with Allegro Cache, and I'd be interested to hear some
experiences from you if you venture to go that route.

Hans

>>>>> darabi  <[email protected]> writes:

> Hi, I sent the below message using the wrong mail address.
> I hope, it doesn't show up twice in the list.:

> ----

> Hello,

> I have a need for persistent knowledge bases and thus
> have been experimenting with the rdbms (and sdbc) system
> which you kindly released some time ago.

> My (maybe short-sighted) conclusion is that rdbms is very
> well suited for accessing large amount of data which
> is already stored in an SQL DB and for making that data
> available to PL's reasoning mechanisms.

> But, if one has no existing SQL data and wants to persist
> a KB of concepts and relations which are subject to frequent
> change, then the limitations of the DB in terms of 'high
> cost' of schema evolution also limit the possibilities
> of rdbms/sdbc.

> Have you or others taken another path: to use object level
> persistence as provided by Franz' AllegroCache or other
> 'object databases' to store the relevant parts of the
> knowledge base?

> Of course, this would only work in the lisp version of PL,
> so it might be out of scope. OTOH, there is also db4o for
> Java and C++, so maybe it wouldn't be impossible to implement
> it in a cross-platform way.

> But, I would be interested in any thoughts you might have
> on this topic. Would it be possible to use the CLOS version
> and identify some classes (e.g. named-description,
> native-relation, context, module) which make up a PL module,
> and persist them to an object database?

> If yes, could you give me some hints as where to look into
> the code?

> Thank you very much.


> Kambiz



> _______________________________________________
> powerloom-forum mailing list
> [email protected]
> http://mailman.isi.edu/mailman/listinfo/powerloom-forum