[vivace-graph-devel] elephant

[MON KEY]

Hi Kevin,
Thanks for your detailed response.

>> Naively, I would expect the MOP stuff to be a factor. Is it?
> Yes, who needs the MOP in this circumstance?

No clue, I'm not suggesting it is needed :)

> I would prefer triples to be stored in memory as vectors (using the args to
> defstruct to force the use of vector storage) for the sake of efficiency.

OK.
Yes you can mark them read-only too.
Also, on SBCL there is maybe some potential gains to be had
with `sb-ext:freeze-type'

> Think about what a triple really is:
>   each S, P or O is a completely unique thing in the database.

I'm not entirely comfortable with that assertion.

To the extent with which it is currently so I'm not convinced it can't be
otherwise (e.g. with namespaces).

I would think the S, P, O are only completely unique within some context:

 (let ((context 'outer))
   (let ((s "FOO") (p "IS-A") (o "BAR"))
     (print context)
     (print (list s p o))
     (let ((s "FOO") (p "IS-NOT-A") (o "BAR")
           (context  'inner)
           (new-foo  '())
           (new-bar  '()))
       (setf new-foo s  new-bar o)
       (print context)
       (flet ((test-var-mk3 (test var init)
                (apply test
                       (list var (make-array 3
                                             :element-type 'character
                                             :initial-contents init)))))
         (print `((,s ,(test-var-mk3 'eq    s new-foo)
                      ,(test-var-mk3 'eql   s new-foo)
                      ,(test-var-mk3 'equal s new-foo))
                  (,o ,(test-var-mk3 'eq    o new-bar)
                      ,(test-var-mk3 'eql   o new-bar)
                      ,(test-var-mk3 'equal o new-bar)))))
       (print (list s p o))
       (setf s nil p nil o nil)
       (print (list s p o)))
     (print context)
     (print (list s p o))
     (values)))

> Because nodes don't repeat and are atomic symbols, traversing the tree
> would be a linear search at each level.

OK. Thank you for this explanation.

I think i have been conflating the demands of triple indexing with the demands
of dereferencing triples/graphs from the persistent store.

This said, I'm not at all comfortable with the current explanation w/r/t the
semiotics around uniqueness and the atomicity of symbols vs strings, and I am
assuming that there _must_ be some level of indirection between objects denoted
by the S, P, and O and the objects which identify these denotated objects.
IOW, i'm assuming there are some over-simplifications around the whole
sign/signifier/signified thang and that this is all well trodden territory
for you and you're simply sparing us the ugly details :)

> In a b-trie (http://www.naskitis.com/naskitis-vldbj09.pdf), you could
> effectively string the S, P and O together and create more reasonably branching
> search paths.  For example, to index the two triples mentioned above with a
> third, (Kevin loves pizza), you would have a tree like:

I'm still reading this paper, although as yet I am completely failing to
understanding how b-tries might easily accommodate namespace/context?

>> Regardless, I personally have a strong desire to keep integration with
>> external (read non-lispy) tools to a minimum.

> YES!

Great! this is really my #1 concern and interest and I should reiterate that
next to a functional persistent VG2 all other details are secondary :)

--
/s_P\