Graph Databases

For a small work project I have been evaluating a variety of graph databases so that I can efficiently model entity resolution. SQL joins are so boring.

Why Graph Database?

On the face of it, storing and modeling relationships between data is what Relational databases are all about, so why would you need a database that specifically models graph structures? 

One compelling argument lies in the way you query relational data versus the way you query graph data. SQL works well when querying data with well defined, node-to-node relationships. For example if you have a table of employees, it is very easy to create a JOIN that will allow you to retrieve an employee and their manager, joined on a manager serial number field. This becomes much more difficult if you want to do something as simple as retrieving an employee's manager chain (especially in large companies). In SQL this would require either a series of queries, or essentially a recursive JOIN. It is possible to do, but messy and potentially slow.

This becomes even more problematic as you model domains where each node has many relationships with many different types of nodes. Take, for example, an online store that has social data connected to it. You would have customers, their relationships with each other, and their purchases and relationships between their purchases (such as X items were bought together). Using this data you could provide personalized suggestions, such as "many of your friends have bought this item recently, and also bought it with this other item". In SQL you would need to union multiple joins against the customer's friends, their purchases and between the purchases.

With a graph-type query, it becomes much simpler, where you start at the customer node, fan out to friend nodes of a certain depth (friends or friends-of-friends) and count up distinct sets of recent purchases.

It is certainly possible to fit a graph query language on top of a relational datastore (such as SPARQL/RDF on top of IBM DB2 or Oracle). Sometimes, however, picking a dedicated tool for the job works better.

Experiments

In typical developer fashion, I used a project as an excuse to play with new tools. In the process I ended up trying 3 different databases that are compatible with Java: OrientDB with the TinkerPop Blueprints API, Neo4j using both the web and embedded java api, and Apache Jena's implementation of RDF.

OrientDB with TinkerPop Blueprints 

Links - OrientDB , Blueprints Plugin

OrientDB is a fantastic document store that is especially notable for its embedded Java implementation. If you ever need to store and query data in a semi-structured way for an application in-memory or with a local cache, OrientDB is a great way to go.

When it comes to graph storage, things get a little bit more complicated. It is very possible to use the native OrientDB API to do graph storage, but using this approach makes querying data a little more difficult. To get around this I tried using the Blueprints plugin for OrientDB to allow me to use a more standardized wrapper for creating and querying nodes in the graph. The idea behind this was that I could switch data-stores if OrientDB was not performant enough. Unfortunately the Bluepages plugin for OrientDB is not yet very stable and this made it very difficult to do things such as indexing nodes based on an attribute. This led to some very ugly code and use of an external index using Redis.

So I gave up using OrientDB.

Neo4j

Links - Neo4j , Cypher

Neo4j is a popular graph database that benefits from a relatively expansive query language called Cypher that allows for some very complex queries and update operations. Neo4j can be used as a standalone server or as an embedded database within a Java application.

When running as a standalone database server, Neo4j provides a very clean REST api for adding, querying and updating nodes. Unfortunately there are no wrapper APIs written to allow a Java application to access the database remotely, you must write your own. This is especially problematic since there is no option to use a binary remote API, so communication is slower than it needs to be and more verbose.

Because of this limitation, I ended up using Neo4j as an embedded database within my application. In order to simplify querying, I used a version 2.0 preview release so that I could assign labels to nodes and query them by their label (or "class" essentially). Everything seemed to go very smoothly and writing queries in Cypher proved relatively easy.

Unfortunately I ran into some issues with stability in the multi-threaded environment of my application. Eventually I was able to iron these out by upgrading to the next preview milestone and locking down all updates and queries to be single threaded. This made high-volume updates very slow, but I was able to mitigate this by surrounding the graph storage with a redis cache that would allow me to identify data changes and only perform updates on change.

Apache Jena RDF

Links - Jena , RDF , SPARQL

Apache Jena is a Java API that supports editing of Resource Description Frameworks (RDF) and graph queries using SPARQL. RDF is a format for describing relationships between objects rooted in Semantic Web data models. The native format of RDF is XML, so Jena supports reading and writing to XML RDF files. In addition to storing to XML files, Jena supports storing to a native Triple store called TDB as well as to relational databases using.

RDF makes heavy use of URIs/namespaces for identifying nodes. This provides good support for classifying nodes into different types and makes relationships between nodes very explicit and self-documenting. The typing system in RDF consequently feels much more mature than those in Blueprints or Cypher. Another benefit from the use of URIs is that it is very easy to create unique nodes, and providing additional data on the node is as simple as providing a REST service that uses the same URI structure.

For my initial implementation I used Jena with TDB for storage, as it allowed me to quickly prototype my data model. TDB supports multi-threaded applications through the use of thread-local transactions, but because of the complexity of the thread model of my application I ended up synchronizing a singleton, so its a bit slow. 

The query language for Jena is SPARQL 1.1 (as of writing). From a pure query standpoint, SPARQL is relatively robust and very well defined (it is a W3C standard). Unfortunately from a performance standpoint, the complex queries I tried to perform proved difficult to optimize because the syntax abstracts a lot of the graph-walking process. Where an equivalent Cypher query would take seconds, a SPARQL query would take many many minutes, or I would give up and kill the query before any result was returned.

Conclusions

After more testing and trying the latest Milestone 6 of Neo4j, it looks like Neo4j is the winner. I attempted some larger scale testing in TDB with SPARQL and it turns out that performance is much worse than I had iniitially thought. Trying to formulate the same queries in SPARQL as Cypher can sometimes turn out to be exponentially worse in SPARQL. Cypher is a bit less abstract in the query structure so it allows you to avoid these pitfalls. This turned out to be a difference between a matter of seconds in Cypher and a matter of hours in SPARQL.

So with Neo4j more stable (thanks to avoiding parallel updates) Neo4j is now the best option for me.

SketchPad Progress

A (sort of) truss diagram drawn in SketchPad.

A lot of work has been completed on the SketchPad project. Here is a quick summary:

Porting Paleo to Android

1. Ported basic classes by removing external dependencies on most of java.awt.* . This involved moving source code from OpenJDK in to replace most of the geometry classes, such as Shape, and all of java.awt.geom.* .
2. Ported shape drawing code to android. This means drawing java.awt.Shape subclasses in an android.graphics.Canvas context. Turned out all you need is to get the PathIterator of the Shape. This code is now in edu.tamu.awt.ShapePainter.
3. Downgraded base java requirements by adding array copy features to the java.util.Arrays class. This allows for downgrading the required level of the android api below 2.2.
4. Removed unneeded classes in dependencies and all Ecology Lab simpl serialization dependencies.
5. Added new serialization code for the core.sketch classes based on Simple XML (simple.sourceforge.net)

Created Android Sketch Application

1. Supports one finger drawing with a color picker.
2. Allows saving files to srlweb for storage and analysis
3. Allows loading files from srlweb

Screen Shots

Shape recognition and beautification at work. Currently it is on by default

A drawing!

Visgo Project Report 2

What we have accomplished in last month:

Related Work - what other people have done to address this problem?

Design - what design we have to address this?

Implementation -

The worst user interface I have used.

One of the worst user interfaces I have used is that of the 3d modeling program, Blender 3d. I absolutely love using the program, but only because I have spent a long time learning its peculiarities, fighting it and looking up instructions.

(Blender 3d 2.5 beta default UI layout)

Non Standard Interface

The first thing you notice when starting up Blender is how completely different the interface looks than any other program on your operating system, whether Mac, Windows or Linux. It is not entirely clear if there was one original inspiration for the UI widgets used by Blender, but it is clear that they were built from the ground up for the program. This leads to behavior such as a typical horizontal spinner UI elements that requires the user to Shift-click on it to be directly

editable. Though this Shift-click to edit behavior is consistent across most of the interface

widgets, it does not follow any established widget interaction conventions and thus is not

intuitive even to people who are used typical window based GUIs.

(An example of a Shift-Click spinner. In previous versions of the program shift-clicking would be the only way to be able type it a specific value)

Speaking of windows, Blender throws out the entire window convention, opting for a single window with re-arrangeable sub panels. It is easy to understand why you would not want to have to contend with layers of floating windows cluttering your screen while trying to move quickly through many different functionality modes. What is not understandable is the

arbitrary solution that Blender comes up with to handle sub panels. To create a new panel, say for a new view of the 3d editing space, the user must "peel off" a new

panel by dragging it from the corner of an existing panel. This is easy enough to do, and users often inadvertently create new panels constantly while trying to resize existing ones. But to get rid of these new panels is tricky as there is no visible way to get rid of them. Most panel or window systems use the convention of a small 'x' icon or the sort to indicate where you click to get rid of a panel. Blender requires you to click and hold onto the same area you clicked to create the panel, then drag to merge the panel with a neighboring panel.

(An example of the "tear-away" corner of a panel. Disregard the "plus" sign, it does something different)

I appreciate that it is occasionally necessary to develop completely new interfaces to handle complex or new interactions. There is no reason, however, to throw away classic tropes of user interfaces when they have been shown to be flexible. Re-inventing the wheel is not always necessary.

Steep Learning Curve

Typically there is a tradeoff between how easy it is to learn to use a program and how complex the functionality of that program can be. This is no different in 3d modeling programs, where it is typical for users to spend a long time mastering the interface and functionality. Blender, however takes the high learning curve to an extreme. The interface itself provides very little hint of how to use it, is minimalistic on visible controls and expects the user to primarily use keyboard shortcuts. Keyboard shortcuts are not a bad means of control if they are consistent and have some sort of mnemonic mapping, but keyboard shortcuts in Blender change functionality depending on which mode you are in, operate with multiple modifier keys and seldom make mnemonic sense. This all adds up to an imposing learning experience that can turn away new users, whether they are experienced with other 3d programs or are new to modeling and are interested in learning the ropes. It is particularly dissapointing that complete newbies must face such an imposing learning curve since Blender is one of the few high quality free modeling programs, the perfect price for budding artists trying to learn the ropes.

Despite all of these problems, Blender eventually makes an odd sort of sense for me to use. Perhaps I suffer from Stockholm syndrome.

Best user interface I have used.

The best interface I have used is the interface of my second generation iPod touch. Functionality is pretty self evident, the user model is simple, the input mappings are either natural feeling finger motions or explicitly written out and above all it is (still) fun to use.

Clear Input Mappings

The biggest advantage of using a multitouch screen with (almost) no physical input buttons is that mappings between inputs are necessarily limited. If the application designer wants to have the user interact with the interface they must either put a button on the screen that performs a specific purpose or use one of the well established finger gestures that are present throughout the system, such as two finger pinch for zooming or one finger vertical and horizontal swipe for scrolling. This leaves little room for the ambiguous input mappings that can be found in systems with more physical buttons. As I have more recently moved to an Android mobile device this has become more clear, as the functionality of the hardware buttons often changes from application to application and even within the context of the core operating system.

Simple User Model

The simplicity of the user model in the iPod touch is another strong point. By this I mean it is clear what is going on with the system when you are using it. If you press on the button of an application it turns on and you use it. If you press the home button the program goes away and you do not have to worry about whether the application is still running, whether you saved what you were doing, whether you quit it properly. All of that is handled by the application and OS, with the only exception to this function being the music player that can run in the background. Again this is in comparison to my recent Android device, where it is never quite clear what state a program will be in when you return to it. Did it quit when you left it? Is it still running and consuming battery? Did it crash? These questions are simplified in the single application/process at a time user model of the non-multitasking version of iOS.

Fun to Use

Finally one of the things that impressed me the most when I first started using the iPod touch was how fun it was to interact with things with your fingers. This was compounded by the smooth and logical way things moved. I honestly spent hours idly scrolling between the home screens on the device because the movement was very satisfying. The kinematic scrolling introduced to handle scrolling through long lists was similarly satisfying. Scrolling through a long music library looking for a particular song was easy and actually fun, where performing such a task on a traditional ipod or laptop would be a long, imprecise process.

CHI Project Ideas

Here are a few ideas from the January 27th brainstorming session:

#1
Augmented Reality Virtual Interaction Space -

You use fiduciary markers to demarcate a virtual interaction space on a surface, most likely a table. You then use networked mobile devices to place virtual objects on the surface and interact with them. For example you could place a document on the surface with one device, then pick it up with another device, or interact with it on the surface.

Basically microsoft surface but virtual and displayed using augmented reality on multiple mobile devices.

The purpose of the system is to be able to create a virtual collaborative workspace on any flat surface, a real world table for example. The user's mobile devices would then act as "portals" into the virtual space by using augmented reality. If a user is a few feet away from the table and holds up their phone/pad, they see the real table but with virtual documents placed all over the table. As they move closer the documents become bigger and bigger until they place their device directly on top of where the virtual document resides in the physical space. The effect would be like putting a small picture frame over a 8.5x11 sheet of paper. The user can then pull the virtual document into their device, if they wish, and take it off of the virtual workspace. Similarly the user may take a document that resides on their device and place it into the shared virtual workspace.

The user may also edit documents directly in the virtual workspace using their device. For example, a user holds their ipad over a picture that they have placed on the workspace. They can now edit that picture through the ipad. If they wish to edit only a portion of the image they can "picture frame" a particular section of the image by placing the iPad directly onto the surface. If on the other hand they want to edit the whole image at once, they hold the ipad a little bit further away from the surface so that they can see more of the image through the picture frame, effectively getting a zoomed out view of the workspace.

This is basically an embodied 2d virtual workspace using mobile devices as both the viewer and the means of interaction.

As far as implementation goes, this would all be done by demarcating your virtual workspace on a real table with AR markers (fiduciary markers) and combining the visual location of these markers with they gyroscope in an iPhone. I do not know if this would be really possible, a subset probably is. But hey, dream big.

#2
Predictive Theories for finger/thumb interactions on tablets -

Manoj pointed out that he has had trouble finding good predictive theory on using thumb and finger interactions on tablets. This would be likely studying hand grips on tablets, sizes of tablets, how people have to hold them to perform certain tasks and what sort of limitations this places on their ability to interact with the software on the tablets.

624 #28 Dixon,Dasarp,Hammond - iCanDraw?

Introduction

This paper presents an assistive feedback system for hand drawing human faces. It is meant to help teach students how to draw a human face and help them see where to make corrections to make their drawing more accurate. The system does this automatically by constructing a drawing template from the reference image that the user has chosen to draw from. The user's drawing strokes are then compared against the template to see if they need correction and feedback.

Discussion

iCanDraw is a nice different way to apply sketch recognition ideas. I personally would like to use some of the design principles that come from this paper to create other such systems, such as for teaching users one and two point perspective drawing.

624 #27 Davis, Colwell, Landay - K-Sketch

Introduction

K-Sketch is an animated sketching system, a tool that aims directly at one of the main purposes and uses of modern pen based interfaces, drawing and animation. The focus of the work is not only to build a tool that makes animation simpler and easier, but also to develop and refine interaction techniques for sketch workspaces. In a user study comparing K-Sketch and PowerPoint in an animation task, it was found that the users were able to learn to use K-Sketch much faster, and generally felt that K-Sketch require much less cognitive load.

Discussion

Frankly it is a little bit surprising that they compared creating animations between K-Sketch and Powerpoint. While powerpoint can do animations, it is well known that Microsoft products usually require a high cognitive load and are not particularly easy to use. Additionally it seems that an actual animation program would be a better comparison, such as Flash or something like it. Still I expect the results would have been very similar, because the controls of K-Sketch seem well thought out and do not overly crowd the interface.

In other news the manipulator tool used in K-Sketch looks very similar to the manipulator tool in Prezi (or vice versa rather).

624 #26 Gabe Johnson - Picturephone

Introduction

Picturephone, as discussed earlier on this blog, is a game developed to build sketch recognition datasets. The game asks multiple players to simultaneously draw a picture based on a text description. This results in the "same" drawing but visually the results are completely different. Generating sketch testing data with this technique allows for a much broader set of images, but at the same time they still depict the same concept.

Discussion

See discussion here

624 #25 Eitz, Hildebrand, Boubekeur, Alexa - Image retrieval based on sketched feature lines

Introduction

This paper describes an image descriptor that allows retrieval of images from a database based on a sketched drawing as input. The descriptor, a Tensor descriptor, is proposed for use in stead of an edge histogram descriptor. The tensor descriptor works by finding the direction of the image gradient in subsections of the image. This descriptor is calculated for every image in the database, then it is calculated for the sketch that is submitted for querying and the descriptors in the database are compared against it. The tensor's performance was better than the edge histogram and subjectively the users of the system preferred the results returned by the tensor.

Discussion

Where can I find one of these? It would be a great way for artists to search for material, for people to be able to look up places or things that they remember visually. It would be interesting to try to visualize your own dreams by sketching out thoughts and seeing what is returned by the search. I hope that Flickr or some other large scale repository picks up on this as a search technique.

624 #24 Gabe Johnson, Ellen Yi-Luen Do - Games for sketch data collection

Introduction

This presentation introduces two games that can be used to collect sketch samples as well as associated metadata or textual description for context. The first is Picturephone, which is very similar to the party game of the same name, except that it is played on a website and players can submit either new descriptions for drawing, new drawings from concepts or rate drawings. The second game is Stellasketch, a game which asks a user to draw an image based on a prompt which other players will then see and use as a clue to figure out the current theme of image prompts. Both games would provide traditional sketch samples, that stroke and timestamp information, as well as ratings and descriptions, all of which are useful elements to data for use in training sketch recognition systems.

Discussion

Systems such as this are some of my favorite topics in computer science. The use of people as "Mechanical Turks" while at the same time entertaining them and providing solid data is a very appealing idea. If you can present people with motivation to help solve problems that are inherently human, while at the same time keeping the task straight forward and engaging you will have no lack of useful data. Imagine if solving puzzles in your favorite game actually solved real world problems at the same time, wouldn't it be ten times more addictive and interesting to play? (I am looking at you PopCap!)

624 #23 Hinckley etc. - InkSeine

Introduction

InkSeine is a sketch input overlay interface that is focused on providing search functionality to support active note taking tasks. The system lets the user mingle ink notes, search queries and documents in one space, acting as a sketch workspace for research, design or creative activities.

Discussion

It is interesting that the main focus of InkSeine is in-situ searching, though it makes sense when their primary user task is note taking and analysis of their personal document collections. I would think personally that users would not want handwritten notes all over their computer workspace, but the idea of having that information available for later access in its original context seems compelling.

624 #22 Mori, Igarashi - Plushie

Introduction

Plushie builds off of Teddy and provides an interface not just to create 3d models but to construct a simulated plush toy. From this simulation the system is able to generate patterns and instructions for assembling the plush toy in real life. Editing can either be performed using techniques of Teddy on the 3d representation, or directly on the 2d construction pattern. While editing, the 3d representation also runs a "plushie" simulation that gives an accurate representation of what the final shape will look like .

Discussion

I did not think I would see anything more brilliant than teddy but this is an amazing combination of natural interaction and physical modeling all working together to simplify an inherently difficult problem. Even professional balloon designers, who were interviewed as part of the user study process for Plushie, felt that the software could help them decrease design time for new balloons.

624 #21 Igarashi, Matsuoka, Tanaka - Teddy

Introduction

Teddy is a system that turns 2D freeform strokes into 3d objects by extracting 2D silhouettes from the sketches. The system is easy to use and it typically took novice users only 10 minutes before they were able to start making 3D shapes. Teddy supports several 3d editing commands, such as creating new objects, painting on the surface, extrusion, cutting, smothing and transformation.

Discussion

Teddy is quite amazing as it really truly takes advantage of sketching as a natural input form to make a task like 3d modeling, which typically requires a long learning curve, simple and quick to learn. The only issue with teddy is that it requires explicit editing modes, but I suppose it is necessary given the complexity of the domain.

624 #18 Shilman,Viola - Spatial Recognition and grouping of text and grpahics

Introduction

This paper discusses a spatial approach for recognition that is quick and efficient. The strokes of the sketch are connected in a proximity graph, then a classifier determines if the strokes compose part of an already classified shape. The classifier only uses a small subset of the features (image, curvature and endpoints) to increase recognition speed.

Discussion

While this approach is very efficient at achieving recognition for the given set of shapes, it is not as flexible as a geometrically based recognizer. The first issue is that each gesture is limited to 6 strokes, which is fine for gesture recognition but is constraining in an actual sketch environment that is supposed to be free form. Secondly the classifier is based on non-deformable templates so objects like arrows must be drawn as the template specifies and cannot be shaped differently.

624 #17 Bishop, Svensen - Distinguishing text from graphics in on-line handwritten ink

Introduction

This paper presents three methods for analysing text vs shapes in sketches: a multilayer perceptrion neural network (MLP), a hidden markov model (HMM) and a bi-partite HMM. These methods can be layered on top of each other to get a more complete picture of the stroke type. The MLP is the lowest level and attempts to identify strokes by constructing a feature vector of 9 features for each stroke and running them through an MLP to identify their type. The uni-partite HMM combines the individual stroke knowledge of the MLP and combines it with information about the temporal context of the stroke and those that came before it. The intuition with this HMM is that text strokes will follow text strokes and graphical strokes with follow graphical ones. Finally the bi-partite HMM adds information about the spatial context of strokes, how close they are to preceding strokes. In experiments, they found that the addition of the temporal context helped recognition rates for the MLP, but it was not always the case that the spatial context helped.

Discussion

It is interesting that they compared several layers of recognition in this paper, rather than entirely different techniques. Also of interest is the set of features that they chose for their feature vector, though it is not clear why they chose that particular set (perhaps from their own previous work). The combination of static classifiers and

on-line classifiers was particularly interesting as it showed how dependent this method is on training data.

624 #16 Segzin An Efficient Graph based recognizer

Introduction

This paper introduces a graph based system for recognizing symbols. Graph structures are used to represent the primitives that make up a symbol and how they are connected, geometrically and topologically. The recognizer is trained by creating these graph structures for each example sketch, then building average graphs that represent the individual symbol classifications. Four graph comparison algorithms were then compared for use in recognition, a stochastic search, error driven matching, greedy search and geometric sort matching. Stochastic, error driven and greedy search all achieved similar top-1 recognition rates, around 93% with relatively close running time, with stochastic being the slowest and greedy being the quickest. Geometric search was much faster, 2ms compared to the 12ms of greedy or 68ms of stochastic, however its top-1 recognition rate was lower, at 78%, and was aided by drawing consistency between users in the study.

Discussion

I like the search methods presented in this paper, and the fact that they can be applied directly to a symbol recognition system. Such a system lends itself to future improvements in search speeds, and would seem ideally suited for other optimizations like parallelization. This is in contrast with other recognition systems we have been introduced to which have not appeared trivially parallelizeable.

624 #12 Constellation Models: Sharon

Comments

Introduction

This paper introduces Constellation Models (pictoral structure models) from computer vision as a method of sketch recognition. Constellation Models are used to identify the subcomponents of complex shapes, such as faces. This is done by using features of individual shapes as well as shared features between shapes to apply labels to shapes. In the case of recognizing parts of a face this would mean identifying that an ear has a relatively ear-like shape and that it is located a certain distance to the side of the eye and nose.

In order to make this method more efficient, as it is at heart an O(n^2) algorithm, Sharon defines certain sub-shapes as mandatory or optional. The mandatory shapes are a smaller subset of the total shapes and are identified first. Once the mandatory shapes are labeled they serve as a solid anchor for labeling the the optional shapes. The algorithm is further optimized by using a multipass algorithm that starts with a very optimistic threshold for identifying shapes and progressively gets lower, identifying more shapes as it progresses and narrowing down the search space as it goes.

Discussion

I like the Constellation method mostly because of the simplicity of the feature vector. The features calculated for each stroke are very simple but when used in conjunction with the relative positioning and shape of other strokes work as a good means of labeling. It is amazing to see some of the example sketches which have wildly varying sub-shapes, but due to their relative positioning all are identified correctly.

I do, however, have some problems with the paper as a whole. There does not seem to be much evaluation of recognition rates or failure points. There is a lot of discussion of the speed of the method, which is important, but what good is speed if you are mislabeling a large portion of the elements?

Another question is how this functions and deals with multi stroke shapes. Most of the example sub-shapes are single stroke, though there are a few that must be multi-stroke. It is not clear if these are grouped and labeled as a single shape or they are treated as multiple shapes of the same label.

624 #11 LADDER: Hammond

Comments

Drew

Introduction

LADDER is a system for describing and recognizing hand drawn shapes using a human readable geometric description language. This is meant to allow system designers to create sets of shapes that can be recognized as part of a visual grammar, that is a certain domain. In addition to shape recognition, LADDER also allows designers to describe how recognized shapes should be displayed, what actions can be performed on them or what actions they perform on other shapes.

Shape structures can be made up of basic recognition shapes, such as lines, poly-lines, circles etc. as well as previously defined shapes. Constraints can then be placed on the relationships between these subshapes.

The system uses these descriptions in a bottom up approach, starting with identifying basic shapes from strokes, constructing many higher level shapes from each basic shape. Eventually each shape is part of one high level shape.

Discussion

LADDER is very useful for domains with simple geometric shapes that are easy to describe either individually or as part of a hierarchy. This becomes problematic with more complex individual shapes that are hard to describe. It might be interesting, as mentioned in LADDER's future work, if a designer could automatically generate a LADDER description of a complex shape, both to make it easier on the designer and to show which shapes might be problematic for LADDER to describe at all. In such cases it would seem useful if a designer could use some other manner of recognition to describe a particular shape, but could then use that shape in a later LADDER description. This way LADDER could incorporate more complex shapes while still keeping the geometric descriptions to create composite complex shapes.

The question we all want answering....

"Does the generative annealing activation information composition visualization in the hot space, driven by information semantics, a user-interest model, and a res- ponsive crawler, help people to be creative?"

From Provocative Stimuli, Kerne et all, CHI 2011