Archive for the ‘Traversal’ Category

GraphPack

Wednesday, July 11th, 2012

GraphPack

From the webpage:

GraphPack is a network of autonomous services that manage graph structures. Each node in those graphs may refer to a node in another service, effectively forming a distributed graph. GraphPack deals with the processing of such decentralized graphs. GraphPack supports its own traverse/query language (inspired by neo4j::cypher) that can executed as transparently distributed traverses.

Amit Portnoy wrote about GraphPack on the neo4j mailing list:

The prototype, called GraphPack, has a very lite design, actual persistence and communication aspects can be easily pluged-in by injection (using Guice).

GraphPack enables transperantly distributed traverses (in a decentralized graph), which can be specified by Cypher-inspired traverse specification language.

That is, clients of a GraphPack service (which may have a graph the refer to other nodes in other GraphPack services) can write a cypher-like expressions and simply receive a result, while the actual implementation may make many remote communication steps. This is done by deriving a new traverse specification in every edge a long specified paths and sending this derived specification to the next node (in other words, the computation moves along the nodes that are matched by the traverse specification).

Sounds like there should be lessons here for distributed topic maps. Yes?

Conditional Traversals With Gremlin

Sunday, July 8th, 2012

Conditional Traversals With Gremlin by Max Lincoln.

An eligibility test that depends upon the ability to traverse to a particular node in the graph.

Reminded me of my musings on transient properties/edges.

Is not choosing an edge is the same thing as the edge not being present? For all cases?

Max mentions that NoSQL Distilled says this use case isn’t the typical one for graphs.

My suggestion is to experiment and rely on your own requirements and experiences.

Authors have to paint with a very broad brush or their books would all look like the Oxford English Dictionary (OED). Fascinating but not for the faint of heart.


BTW, when looking up the reference for the Oxford English Dictionary, the wikipedia reference mentioned that:

The Dutch dictionary Woordenboek der Nederlandsche Taal, which has similar aims to the OED, is the largest and it took twice as long to complete.

I don’t read Dutch but the dictionary is reported to be available for free at: http://gtb.inl.nl/

If you read Dutch, please confirm/deny the report. I would like to send a little note along the the OED crowd about access as a public service. (Like they would care what I think. ;-) Still, doesn’t hurt to comment every now and again.)

Jogger: almost like named_scopes

Sunday, March 4th, 2012

Jogger: almost like named_scopes

From the post:

We talked about graph databases in this and this blog post. As you might have read we’re big fans of a graph database called neo4j, and we’re using it together with JRuby. In this post we’ll share a little piece of code we created to make expressing graph traversals super easy and fun.

Jogger – almost like named_scopes

Jogger is a JRuby gem that enables lazy people to do very expressive graph traversals with the great pacer gem. If you don’t know what the pacer gem is, you should probably check pacer out first. (And don’t miss the pacer section at the end of the post.)

Remember the named_scopes from back in the days when you were using rails? Jogger gives you named traversals and is a little bit like named scopes. Jogger groups multiple pacer traversals together and give them a name. Pacer traversals are are like pipes. What are pipes? Pipes are great!!

The most important conceptual difference is, that the order in which named traversals are called matter, while it usually doesn’t matter in which order you call named scopes.

A nice way to make common traversals accessible by name.

Does the “order of calling” scopes in topic maps matter? At least for the current TMDM I think not because scopes are additive. That is the value covered by a set of scopes must be valid in each scope individually.