thi-ng / fabric Goto Github PK

Query specs should be walked recursively and transformed with given fact transform where possible...

Must differentiate between patterns and expressions (use ff/transform vs. ff/untransform)

Non-tech users would benefit from a graphical web UI to define queries by "drawing" out the graph patterns and qvars to be matched. The s-expr DSL is also well suited to be built up incrementally (e.g. via dropdowns and then filling in or visually linking placeholders to qvars/literals)

Ideas/tasks:

• update results w/ each edit for direct feedback loop
• display results as graph (super-imposed) or table
• use thi.ng.geom.physics for graph layout

Prior art:

• http://lod.openlinksw.com/isparql/ (click on graph icon in toolbar)
• http://osm.cs.byu.edu/CS652s09/papers/Smart.NITELIGHT.EKAW2008.pdf
• http://www.visus.uni-stuttgart.de/uploads/tx_vispublications/VisualSPARQL_AVI2014_preprint.pdf
• http://svn.aksw.org/papers/2015/ISWC-VOILA_FedViz/public.pdf
• http://franz.com/agraph/gruff/

Interesting project. Thought I'd point out http://www.msr-waypoint.com/pubs/201100/naiad_sosp2013.pdf in case you find some inspiration there

Hi,
Thanks for this library. It looks really interesting and powerful.

I am looking at the spreadsheet example and trying to understand the vertex collection functions. By the looks of it, (f/signal-map v) returns a map of type {<id> value ...}, where <id> is the vertex number in the graph.

Is it possible to change that <id> into something user specified, so that the end user can reason about which value is associated with which node without trying to look it up in the graph.

I hope this makes sense.

cheers

Users might want to subscribe to registered queries so that when result set is changing, a notification is pushed automatically via WS/SSE.

Ideas/tasks:

• add new vertex type (SubscriptionVertex), where each vertex manages its own subscribers
• add new handler to register/unregister subscriptions

Currently all facts are centrally indexed by the graph's N index vertices (e.g. subject, predicate, object). Not scalable.

Ideas/tasks:

• add index group vertex/entity (set of N index vertices), each providing filter range (or rather predicate fn) of acceptable fact IDs and acts as facade to actual index vertices
• redistribution/re-indexing when adding/removing/failing index groups
• refactor fact vertex adding/removing