David, > Perhaps we have different objectives: you want to explore big graphs > while I want anybody to be able to build a browseable UI for a small > graph.
You are right, our objectives are a bit different, but I think they overall fit quite well together. My goal is to find ways to enable users to explore large graphs and break them down into smaller graphs containing the actual data they are interested in. Analyzing and browsing these smaller graphs works wonderfully with the tools you've created. And in order to create an coherent user experience, these two tasks shouldn't be disconnected. I'm not advocating "Web of Data browsers" like Tabulator here, I'm just looking at how users e.g. in businesses could deal with their information when access to relational databases is opened through tools like D2R server. I remember a discussion a while ago on loading DBpedia into Longwell. Besides raw computational scalability that wouldn't work from a UI perspective as well. > > The group-by feature is neat, but it will break as soon as the user's > path becomes as graph. Then the group-by would need a "refocus" feature > as well to enable the user to explore /what/ he could group-by. > > And then the distinction between these two ways of filtering is more > confusing than helpful. > > > > Maybe my idea of lifting the path to a graph doesn't work at all... > > > You're right that if the path is a tree or graph (with operations like > set union and intersection), then link sliding and group-by would > break. > I'm still thinking of a solution for that :-) Me too ;) And thinking needs some more time at my side before results can be expected... > > Well, I was thinking of the sequence of filters as a kind of pipeline > (I > > steal that metaphor from my colleague Richard here). > > If you think of it as a pipeline, you put in stuff and get a subset > of > > that same stuff out. Navigating the graph is only done to select > > filters, i.e. as you wrote above, the user only temporarily switches > > focus. > > > I did think of query graphs and other designs, e.g., in early 2005 > > http://people.csail.mit.edu/dfhuynh/research/ideas/zoomable-faceted- > browsing/query-graph-2.pdf > > http://people.csail.mit.edu/dfhuynh/research/ideas/nested-queries-in- > faceted-browsing/page-06.png > but I'm not convinced that a pipeline UI is the best. Interesting that you called the first one "zoomable". I've been recently thinking what "zooming and panning" means for graph-based UIs, and I failed to find papers on that topic. And haven't figured it out myself yet... > > I'm not convinced ;) Seems like a good place for a little user > study... > > > You're right on this one, too :-) You don't know how good it is to hear > a SW guy say "user study" :-) :-) Yes, unfortunately scientific methodology isn't very popular in SW research at all. The SW community would be well advised to sometimes remember it is part of the Computer /Science/. I am myself often quite attracted by the "publish some prototype and hope for qualitative feedback from other researchers" method (let's call it "lazy evaluation"), but real scientific evaluation would lead to so much better results. There is a lot to learn from HCI research here! And I've got the bad feeling that people using the lazy method don't even really listen to feedback... It's funny that Exhibit seems to be the most used UI in Semantic Web demos ;) > The group-by feature *as it is implemented* would break... But yes, > DBpedia is a good data set to experiment on. I'm very looking forward to what you could do with a different "group-by" approach! Cheers, Georgi -- Georgi Kobilarov www.georgikobilarov.com _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
