[elephant-devel] a job for the query system?

Ian Eslick eslick at csail.mit.edu
Fri Aug 31 01:45:34 UTC 2007


On Aug 14, 2007, at 6:14 PM, Joe Corneli wrote:

>
> I want to work with some objects like this:
>
>  Things --
>  [key: OID | slots: name, data]
>
>  Triples (subclass of Thing) --
>  [slots: beginning, middle, end]
>
>  Theories (subclass of Thing) --
>  pset (?) of elements: [key: name | slot: OID of some Thing]
>
> Ian Eslick has already helped me by putting together an implementation
> covering Things and Triples in a very slick way.
>
>  http://planetmath.org/~jcorneli/variant-4.lisp
>
> In particular, the current implementation enables the user to find all
> Triples which match on any particular data in the three slots.  Note:
> the schema is not precisely what I've listed above, which brings me to
> my first question:
>
> Question 1.  What should I do to key a persistent class by its OID?

These questions may be too low level and making too many assumptions.

A persistent class can be indexed in many different ways.  By  
default, an indexed class (has class option :index t or any slot has  
option :index t) is stored in an index by its OID.  Currently we do  
not guarantee that OIDs will not change in a migration or GC and  
there is some open discussion about providing a long-lived namespace  
(probably when we move to 64-bit OIDs).

You can create your own OIDs, put persistent objects into BTrees  
directly and ignore all the class indexing stuff.  If you want to use  
the system assigned OID, you can access it directly by (elephant::oid  
<thing obj>)

However, unless you are building a specialized data structure like a  
map, you can just use the object itself as a key in lisp (internally  
this is stored as the object's OID, but it makes things cleaner in  
lisp and ensures consistency across migrations, GCs, etc).  So your  
schema would be:

(class:Thing slot:name slot:data)
(class:Triple slot:beginning slot:middle slot:end)
(class:Theory slot:name slot:<pset ref>)

This pset would have a set of <thing ref>, or instances of things  
which I assume would be triples.

Thus when you iterate over a pset, you get back <thing ref>'s instead  
of OIDs.  This does have some implications, namely creating the thing  
object in memory rather than deserializing an integer, but the query  
system in theory should overcome this.

> Theories have yet to be implemented.  The schema is set up so that
> Things to live in a Universe and Theories designate arbitrary subsets
> of that Universe.  The challenge that I want the data-matching
> routines to work within a given Theory.  This way, a Theory can be
> viewed as a sub-network of the semantic net that the Universe as a
> whole comprises.

> I am pretty sure Ian indicated that this can be done using the up and
> coming "query system".  Which brings me to:
>
> Question 2.  Does this indeed look like something the query system can
> handle?

If I understand you, you want to filter the lookup of a triple or  
thing to be those matching the query criteria but also contained  
within a specific theory?  Expressed in Psuedo-SQL

SELECT triple WHERE
triple.beginning = <Thing name:IsA> AND
triple.end = <Thing name:Cat> AND
member(triple, <Theory name:QuantumTheory>)

This would require that the query system be able to do membership  
tests on psets, if you used the proposed schema then I think this  
wouldn't require a significant change to the query system (just  
another join on the pset index).  The pset functions as a one-to-many  
map, but it can also be seen from the SQL perspsective as a virtual  
column that can be added to any table that provides boolean membership.

> Question 3.  Does this look like a good set-up?

See my points above.

> Question 3.  How can I learn more about this query system and when is
> it expected to be available?

There is some early prototype functionality that is partially in my  
local development tree and partially in the current development  
tree.  Unfortunately I did not finish the query system this summer  
and so its release has been indefinitely delayed.  I will try to get  
the sketch with a basic interface released in the next month, but  
optimizations may be long in coming.

Good luck!
Ian





More information about the elephant-devel mailing list