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
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
