Dear Alberto:

I have been digging deeper into your very interesting work on GraphLog.

What is common between GraphLog and Demeter is that they both achieve a
similar form of structure-shyness. By that I mean that the queries or 
programs can operate on a wide variety of different structures.
The programming language community uses the term polytypic or shape 
polymorphism to express something similar.

Here is a comparison between the two:

GraphLog		both				Demeter
             operates on: graphs (object graphs)
	        structure-shyness achieved by:
graph patterns						strategies
		computation is done by:
graph matching						traversal automaton
simple operations like sum, max, min  			visitor methods

			differences
			complexity, expressiveness
polynomial (NC^2)					Turing complete

matching is slower?					traversals are fast

			elegance, ease of use
VERY elegant when expressible				always works
conditionals are generated				longer than GraphLog
by using constants					queries

			interaction matching/computation
only complete match 					partial match may
leads to computation					lead to computation
							(prematurely terminated
							paths)

I think there is a nice integration between the two systems by
interpreting strategies as object graph patterns. But this requires more
work.

What I am struggling with now is how to evaluate a GraphLog query.
I read your Theoretical Computer Science paper: Low Complexity Aggregation
in GraphLog and Datalog. It describes how this is done by referring
to Datalog work. I was wondering whether you know of a nice, self-contained
description of this algorithm in graph theoretic terms without referring
to many pages of Datalog material in Jeff's book. Is there an 
implementation of GraphLog available?

Also, do you know of teaching material (viewgraphs) explaining GraphLog.

Best regards,
-- Karl
PS. Demeter viewgraphs are in: 
http://www.ccs.neu.edu/research/demeter/course/f97/lectures/