Alright, it doesn't look like much, but there is something special about the web dialog that is being displayed over the 3D graph - it was built triple by triple.  I had reached the point in developing Nexus where I needed to have interactive dialogs for display control and user-input.  Up until this point, I had been working with 3D objects and taking SPARQL commands via a text box at the bottom of the screen, but easier control over visualizations was needed.  Nexus client/server communications works by passing the RDF data that represents the 3D visual displays to the client from the server as RDF over the HTML5 WebSockets protocol with the client sending back any responses to the server back over the same bi-directional WebSockets connection.

But how to handle HTML5 web dialogs?  Also, in keeping with one of the Nexus design principals "it must be collaborative", how would I keep HTML5 dialogs synchronized between multiple clients?  Another Nexus design principal is "it must be RDF".  If you think about it, HTML, CSS, SVG, and RDF are all just data in the end, but four different styles of data formats.  If we have RDF, why not just make them all RDF?  I had looked around and people had asked the question of how to represent actual HTML pages as RDF years ago, but they only comprehensive work I could find on the subject, is TopQuadrant's SPARQL Web Pages. (http://uispin.org/).  TopQuadrant represents SPARQL (as SPIN - SPARQL as RDF) and HTML/CSS as RDF and then processes the combination of RDF data server-side to render HTML pages (in the same fashion as JSP, ASP, PHP) and then passes the rendered HTML/CSS pages to the client.  TopQuadrant even has RDF ontologies to represent HTML 4.01, CSS, and SVG Tiny1.2.

But, I wanted to put a slightly different "spin" on this.  ;-)  I decided I wanted to take the web pages represented as RDF on the server and then pass that data to the client as RDF over the WebSockets and then render the web pages (or fragments) triple-by-triple using the HTML Document Object Model (DOM) client-side.  I created my own HTML/CSS ontologies since TopQuadrant's is weighted towards their SPIN technology.  The above image is a 3D depiction of Tim Berner-Lee's FOAF file as a 3D graph.  The black dialog was built by executing the following SPARQL query against the graph to determine the number of each type of predicate used in the RDF graph.  This is a precursor dialog to allow a user to remove uninformative predicates from the view (for example removing triples that represent gender when you know you are looking at a same-sex population of people).

SPARQL Query to determine numbers of different predicates:
select distinct ?p (count(?p) as ?count)
where {graph ?g {?s ?p ?o}}
group by ?p
order by desc(?count)

After the execution of this SPARQL query, I follow the same model as I do in the 3D visualizations.  You never see your actual data, you see something that is a visual representation of your data.  By having this visualization layer over the actual data, it allows for multiple visualizations of the same thing at the same time.  It also allows for an amazing level of flexibility since visual data can be manipulated by a variety of SPARQL update queries against a combination of the visual data and the actual data (both being represented as RDF). The results are wrapped in HTML/CSS (an RDF version of it) which then creates the final RDF graph which can be viewed in this link (HTML/CSS as RDF).  This is the actual data that is sent over the WebSockets connection to build the dialog.  The client then reads the data triple by triple and then creates the HTML fragment (wrapped in a DIV) and then adds it to the existing web page.  Each row of the table in RDF has a <nex:clickable> set to true on it.  What is this for?  It tells the client to attach an onclick handler to the row.  All rows have a unique ID set.  The onclick handler simply sends a single triple back to the server to indicate which object (row) has been clicked.  For example:

<http://www.ebremer.com/nex/ses/7548c5d4-8ea8-40e8-8726-fa8819a62fe6> <html:event> <html:hasBeenClicked>

It is then up to the server to determine how to respond to the end-user's click.  For what I am working on, at the moment, is that the background color will be set to a "highlight" color which will take a single triple to the client to do.  Keep in mind that another client may be attached to this visualization at the same time and that same triple can also be sent to keep that client's version of the dialog in synch with the client who did the clicking.  There is also no reason why multiple clients cannot click on the same dialog at the same time and on different rows (but on different browsers) for everyone to pick what they want to select.  Singular triple changes allows for alot of flexibility, as well as, a "AJAX-like" experience since no screen refreshes are required on any of the concurrent clients.

Other updates since last blog post:

1) The force-directed layout engine as been re-written to take advantage of multiple cores.  This has greatly accelerated layout computations since I work on a 6-core computer most of the time.

2) The "classic" RDF reification model which allows Nexus to make statements about specific triple's literals and specific triple's predicates has been replaced with a Named Graph version of RDF reification.  The notation is much easier to work with than using rdf:Statement, rdf:subject, rdf:predicate, rdf:object styled reification.  This was done after the newer Apache Jena library was added to Nexus.

3) Creation of a threaded 3D visualization "controller" - the earlier version of Nexus worked SPARQL command by SPARQL command.  In the new version, it can process multiple triples in batches, as well as, run layouts in a separate thread(s) which also enables incremental updates to the current visualization.  Essentially, a user can watch a graph layout occur as it happens.  This has been very helpful in debugging since I can see live what is actually happening.

4) XY/XZ client rotations and zooming with the ablity to alt-click a new center of rotation to allow "camming" through the 3D simulations.  Fun with quaternions!  (http://en.wikipedia.org/wiki/Quaternion)

5) COLLADA duck avatar representation of different clients.  This is needed to let a client know where other clients are collaboratively "looking" in the 3D visualization.  The duck was less boring than a ball or a cube or an arrow. And it makes my kids laugh.  :-)