Lambda the Ultimate

However, once you have this:

print "Julie's male ancestors are:" for a in graph>>Node(ex.julie) //Property(ex.parent)[Class(ex.Male)]: print a

then you'd wonder if Python is going to need more Iconic features:

every print graph>>Node(ex.julie) //Property(ex.parent)[Class(ex.Male)]

every print graph>>Node(ex.julie)//Property(ex.parent)[Class(ex.Male)]

Hmm.

def p(thing):
   print(thing)


[p(x) for x in graph>>Node(ex.julie)//Property(ex.parent)[Class(ex.Male)]]

And presumably, change the outer brackets to parentheses in Python 2.4 to avoid creating a dummy list of Nones that we just throw away...

[later]

Of course (I'll be branded a heretic for mentioning) you can also (ab)use the usual list functions:

filter(p, graph>>Node(ex.julie)//Property(ex.parent)[Class(ex.Male)])

maleAnc = graph>>Node(ex.julie)//Property(ex.parent)[Class(ex.Male)]
print maleAnc*

Is it possible to nest queries, that is to have a query that results in a subgraph, on which subsequent queries can be performed?

Glad to see GraphPath provoking a discussion. Just to clarify what GraphPath can do: yes the examples collapse the results to node sets or to tuple sets (using the projection operator %). But more generally you can think of GraphPath expressions as mappings from DLGs -> DG's. e.g.:

# here is a rule to match any path from a child to aunt aunts = Property(ex.parent)/Property(ex.sibling)[Class(ex.Female)]

# binding this expression to a DLG yields a DG dg = family_dlg>>aunts

# we can use aunt_graph like this: dg.terminals( None ) # all aunts dg.initials( None ) # all children with aunts dg.matches( None, ex.lisa ) # lisa's nieces and nephews dg.values( None, ex.david ) # david's aunts

# turn the dg into a list of 2-tuples: [(i, t) for i in dg.initials( None ) for t in dg.values( None, i )]

I need to get rid of the None argument don't I? Standby.

- Arnold

print "Julie's male ancestors are:" for a in graph>>Node(ex.julie)//Property(ex.parent)[Class(ex.Male)]: print a

I'd like to point out that using SXPath in Scheme, you can write that example something like

(for-each display ((sxpath '(julie // parent (@ (equal? (class "Male"))))) graph) )

or (let ((compiled-query (sxpath '(julie // parent (@ (equal? (class "Male"))))))) (for-each display (compiled-query graph)))

I'm guessing the schema here. SXPath queries look almost the same as XPath queries, modulo parentheses. Also, XPath separates location steps with slashes; SXPath uses spaces.

One advantage of SXPath is that you can use any appropriate Scheme procedure as a node test or a filter. That point is discussed in
http://pobox.com/~oleg/ftp/papers/SXs.pdf
(in particular, Section 3 of that paper).

I'm writing a system, Mneson, based on the UNH. Currently the convention to represent typed links is as follows. A typed link A--B-->C is represented by the subgraph A-->Y, B-->Y, Y-->C. The fact that D has the value (property) E is represented simply as D-->E.

I submit that the three functions

  sources (vertex_or_vertex_set) -> vertex_set
  targets (vertex_or_vertex_set) -> vertex_set
  intersect (set_of_vertices_or_vertex_sets) -> vertex_set

I tested the first case in the GraphPath Introduction, for "females´ (whose parent is Nalda) first name". It gives a long expression with the primitives of the Mneson Calculus, but if we define

^ = intersect
with_attr (name, value)
  = sources (targets (name) ^ sources (value))
with_attr (value)
  = sources (value)
attr_val (subjects, attr_name)
  = targets (targets (subjects) ^ targets (attr_name))

then it is simply

attr_val (with_attr (parent, Nalda) ^ with_attr (Female), firstName)

Not bad for an untyped network, uh?

Now I´m (also) interested in the complexity of this. Mneson is based on optimized data structures (Ada 2005 standard containers). The complexity of "sources" and "targets" is trivial. "intersect" is of course the crucial operation regarding complexity. I'm thinking of ways to optimize it. This includes the observation that is seems that the interesting uses of "intersect" are always binary i.e. the intersections are always of only two sets. If this 'conjecture' is true then I think Mneson might have a bright future.

Mneson is at http:/www.liacc.up.pt/~maa/mneson, for those who don't want to Google. There is a lot of cool recent developments that are not there yet. But will be soon, and sooner if required.

Someone mentioned a system called "Mnesia". Interesting name similarity.

Technical note on the expression above. The occurence of with_attr/2 yields more than the really wanted vertices. Namely the result includes vertex "parent". However this does not affect the result of the expression because "parent" most certainly does not have property "Female", and therefore will be excluded from the resulting set. But this is also an issue to look into.