Danny

Quantitative Filtering

Filtering is a core feature of information presentation on the Web. As an example, look at blogs. This post will visible for a while on this blog's front page, along with the other most recent posts. Essentially the page is defined by a filter (by date) applied to a large collection of material. Filters can work over many different axes, e.g. date, tag, author etc. They can be combined to provide faceted views of the information. Filters like this are fairly common on the Web, often seen combined with an ordering of the data for example: Sort By Price and Show 10 Items Per Page.

Many filters operate over a continuous variable (or one that can be mapped to a continuum), the date of posts being a good example. If you've got a continuous variable then a UI component that becomes available is the knob or slider. It's pretty straightforward to hook such a UI component up to a filter to apply to a backend store (in fact I rigged up a demo of doing this not long ago).

In the context of a blog there is quite a lot of data available that could be used for a knob-controlled filter. For example, most blogs contain a mix of long and short posts. Why not filter on word count? More nuanced things are possible nearby, say link count. Or something like readabilty. To make knobs or sliders user-friendly you probably wouldn't want to offer the viewer the actual numbers of word or links, rather a e.g. slider that had at its extremes Short ---|- Long.

Quantative Tagging

Sites like Amazon also exploit user-contributed data like rating (in reviews). But there's an awful lot more potential kinds of information available. To pick some at random: utility, creativity, authority, entertainment value (fun!). So someone comes along and sees a post with a set of sliders below it and sets those sliders at 4, 3, 2, 1. That data is passed back to the server. Ideally the server will store that data associated with the user in question, to allow the whole social query dimension. Or the value may simply be aggregated as numbers associated with the post.

When someone else arrives on the site they see, say, a default view of the most recent posts. But below are same controls again. They are interested in reading material that's useful and fun, but are less interested in the other factors. So they set the sliders at 5, 1, 1, 5 and click Search. They are instantly presented with posts that fit that profile. The user may want to save that profile so it's the default next time they visit.

What happens under the hood at view time is again something that could be quick & dirty less-than/greater-than filtering on the parameters, or something more sophisticated that derived the results from the "shape" of the settings, amplifying the descriptions previously given by their friends.

Taking the user-contributed data angle a step further, instead of having a predetermined set of controls, it wouldn't be hard (at least if you're using RDF under the hood :) to allow the users to define new sliders, just ask them for the axis over which the slider varies Foo...Bar. Working title, please change: Wiki Knobs.

Interstices

The applications for knobs like these are pretty open-ended. What I describe above is a typical-Web-site-oriented view of an idea my late wife Caroline suggested years ago, effectively an idea generation machine, working title Interstices. I'm not sure she was a big fan of the Surrealist movement per se, but she loved seeing surprising, apparently contradictory concepts combined in art. I vaguely remember (or have imagined :) her talking about it the context of a magazine advert for PCs, where the tower cases had Friesian cattle's black and white markings (anyone remember that?).

With Interstices you'd tag images with sliders as described above, arbitrary scales, say Hard...Soft, Natural...Artificial etc. But then rather than looking for matches, the system would offer you opposites, so the PC is Hard...Soft:1, Natural...Artificial:5 whereas the cow is maybe Hard...Soft:4, Natural...Artificial:1.

I said at the time it would be easy to build - still haven't got around to it. But I'm pretty sure at the time we were only thinking in terms of a little app one or two people might use. Imagine something like this supporting proper crowdsourcing, e.g. sliders attached to Flickr. That'd be cool.

Comments to G+ please

Not a new idea, but I thought I'd try and find out how far we've got and braindump a little. I'm making the fairly big assumption that a general-purpose data browser would feasibly useful/usefully feasible in addition to application- or task-specific tools (i.e. use X for your contact/social data, Y for your project management data, Z for your shopping list).

Historically Web browsers provide simple display of (linked) HTML documents obtained via a subset of HTTP, and that's still their primary use. Not very promising for use on the Web of Data without a lot of server-side magic.

But, as well as supporting increasingly sophisted UI elements, they have built-in support for a Turing-complete language, Javascript. The HTTP limitations can be worked around. So while there may still be potential for a totally new breed of data-oriented Web browsers built from scratch as Rich Internet Applications, current browsers have the potential do do whatever's needed. Although they're pretty much limited to playing a client role, in effect they can be whatever kind of Intelligent Agent you like. The bonus is that everyone's already got a browser on their desktop/tablet/mobile - it's an easy path to deployment either for a plugin or better style as code-on-demand.

What's needed for a Data-Oriented Web Browser?

I'm not sure if the Tabulator is still actively maintained (if not, why not!?), but that gave a good indication of the kind of thing that is possible. Taking a step back, the Web of Data is really the same thing as the Semantic Web, and what's new about the Semantic Web isn't the "Semantic" but the "Web" (once again I've lost the source of that quote). How did/do people work with data without the Web? Typically SQL databases and spreadsheets. From those we can lift SQL queries and command-line tools, stored procedures and database forms (this is rather a confession, but back in the day when I first encountered MS Access it blew me away). Then of course there's the spreadsheet UI paradigm, a grid of cells which can be filled with pretty much anything, including most significantly on-the-fly calculated values.

So here's an initial shopping list:

an in-memory* graph data structure support (rdfstore-js looks the most advanced right now)

a spreadsheet-like view (I bet David Huynh has got stuff like this, if not, how hard could it be with a and jQuery? :)

a little language for concisely expressing Web operations, e.g. running SPARQL queries, that could be used inside the spreadsheet (the RDF path-following DSL in Apache Clerezza could be useful here too - link please Henry)

tools for building app-specific forms (quite a few tools support custom views of particular classes, e.g. foaf:Person, Fresnel might help here)

the ability to write as well as read data (this shouldn't need saying)

* persistence would be provided by the Web

I doubt it's possible to say up front what would be a good user-friendly way of setting this stuff up. But given a bunch of scripts that supported these elements, I reckon with a bit of trial and error dogfood use, within a few iterations something really useful could be possible.

Thoughts? Volunteers? Startups? :)

I've still not got commenting set up here so please post any feedback to this Google Plus entry.