Fork me on GitHub

I’m very excited to get into Asami for the graph algorithms, and I’m looking for anecdotal experience about it’s current limits.


Limited to in-memory graphs right now


There are only a few things. It can find shortest paths between nodes. It can identify all subgraphs. It can find a subgraph that a node is part of. It also integrates into Loom, and will respond to the algorithm APIs there as well


Great! I use ubergraph in memory now to find connected components, so I think it will work just fine!


I ought to write up how best to use these things. They’re there but they are probably hard to find 😕


It’s a case of identifying a need that my team has (or occasionally, something that I think seems interesting) and then my team decides not to bother using it.

😀 2

Identifying all disconnected subgraphs was an operation that my team definitely needed. And then they decided to do something else after I made it. Sigh.


But it’s open source, so I’m hoping that others may gain benefit from it 😊


I know the feeling! I like the docs a lot, actually


Thank you!


But this is prompting me that I need to write up some of the analytics operations


I’m build an id graph from our company id’s (netid, email, hr-id) to find issues. I think this will work


I’m currently writing some SPARQL queries to detect whether SKOS concept schemes conform to various topologies; i.e. whether they’re flat, tree, dag, cyclic-graph etc… Those tasks turn out to be pretty trivial queries; and will almost certainly be in asami too. The most complex of them is detecting cycles, and that’s trivial with property paths.

👍 7

Cool! I talked a bit about cyclic queries in the context of Crux for a recent Clojure Provo meetup, and wrote some tests to benchmark performance: Crux is slower than, e.g. DataScript, but doesn't OOM as the data set increases. How have you found memory usage to be whilst detecting cycles?


I don’t know. For my implementation it’ll be dependent on the underlying database as it’s done in a single SPARQL query with a property path, and the graphs I’m working with are small enough to live in memory anyway. I would expect the query to be memory bound though it’ll depend on the implementation. For my data cycles are a very rare edge case, and one of the main reasons for testing it is to invalidate certain graphs and avoid running algorithms that may not terminate in the presence of cycles over the data.


> the graphs I’m working with are small enough to live in memory anyway ah okay, that definitely tips it in favour of just doings things outside of whatever durable store you use 🙂