Continuous graph exploration frontend

[gtfierro]

Want a new part of the frontend: as user types in query, we get a continuously updated class graph of the results, with the union of the "one hop" relationship/classes from each of the items in the result.

Depends on #3

[gtfierro]

Now that the basic "2 var" queries including predicates (?s ?p o, s ?p ?o) are working, we can start deciding how to build this front end.

Use cases:

1. Building a query: the user types in a BRICK query. The frontend renders a class graph of the results. When the user clicks on any one node (either a class or a variable), the frontend renders a table (under the graph) of the current values for that variable or the current items that belong to that class.

2. Graph exploration: when the user types in a BRICK query, the frontend renders a class graph of the results as before. However, it also now renders the 1-hop edges and nodes from each node in the graph. This should be possible using the "2 var" query terms.

---

Implementing this requires the following steps:

• Class graph -> DOT api endpoint.
  Should be able to generate class graph from the results of a query, not just the underlying Turtle file as it is done now.
• Query rewriting for doing graph exploration.
  For a query such as

  SELECT ?vav WHERE {
    ?vav rdf:type brick:VAV . 
  }

  We need to rewrite it asking for the predicate and objects coming off of every variable in the term.

  SELECT ?pred ?obj WHERE {
    ?vav rdf:type brick:VAV . 
    ?vav ?pred ?obj . 
  }

[gtfierro]

As of eb5c157 we have a basic implementation of graph exploration.

However, its not very usable and is a bit confusing.

Other thoughts:

• just render the class graph for the query, but when a user clicks on a node, it "expands" the graph with the predicates/objects reachable from the clicked node
• when a user clicks a node, render the list of instances of that class

[gtfierro]

Nice update in 89c8462 that uses a basic d3 visualization to render the graph. This is much more stable to use than the vis.js approach

[gtfierro]

Going to check this off for now, but subsequent releases should explore how to best implement this.