The Tabulator project has three different kinds of interface: the standard data view, generic panes, and application specific panes. The standard data view shows you all the raw triples, whereas the generic panes show you things like a calendar of all dates mentioned in your data, or a SPARQL query interface.

The application specfic panes are for things like FOAF (social networking), SIOC (community networking), and DOAP (open source project description). So the FOAF pane, for example, is an interface to a distributed social networking site, having inputs such as "search for this person" and buttons like "make this person my friend". DOAP may have a "describe a new project" button, and then a dropdown for "select a DFSG approved open source license".

When you have only three applications, it's not so difficult to write panes for all of them if you're on the Tabulator team. It might take some weeks or months, but it can be done. But what about when there are a dozen such applications for the Semantic Web? What about fifty, or a hundred, or a thousand? It'll be infeasible for the Tabulator developers to keep adding panes; it just won't scale.

So that leaves at least two options. Either the inventors of new applications will create panes, or interested users will create new panes. For this to happen, Tabulator would already have to have fairly substantial use, because making panes is a big effort.

There are a couple of approaches that might make it easier to go from a quick outline of a project, say a human readable specification and a bit of OWL as seems to define most Semantic Web applications at the moment, to a pane. The first is Fresnel, which is a display vocabulary for RDF. In other words, it's a kind of stylesheet language in that you give it some RDF input and it can render some output, perhaps as XSL-FO, perhaps as SVG, perhaps as HTML 5. But really, that's just a tool for making a pane—it might make things a little easier, but it's not going to cut the time required to make a pane by 90% or anything so grand.

The other approach, that Daniel John Lewis considered on #swig recently is to have a language that generates the interfaces from the semantics almost entirely automatically. At the time I replied that “I think there'd need to be too much hinting involved, though; in other words, I don't think there's a way to generate a UI from a bunch of semantics, like an OWL ontology for something or whatever you've got lying around”, but perhaps it is in fact possible for some of the simpler cases? If you look at the FOAF, SIOC, and DOAP examples given above, they're all quite simple interface idioms: make this person my friend is just adding a foaf:knows arc between two foaf:Person nodes. Describe a new project just makes a new instance of doap:Project. It's fairly simple stuff as far as the interaction is concerned. Structuring the data for display might not be much harder.

More complex parts of the system, such as "search for this person", on the other hand, would require at least some effort on the part of the pane designer; they would, at the very least, select a particular service or set of services for inclusion in such a way as to make them programmatically available. This might be made a lot easier if the interface is described in some kind of web services description language, should a good instance of one exist (ahem), but there's going to be some effort there.

As for the question of how this will all scale, I think that Semantic Web developers should be concerned; and the Tabulator team and others like them especially, if they don't yet have an answer in mind about this. The FOAF level applications are all fine and dandy, but I can't say that I use, say, Facebook more frequently than I find interesting Geocities sites—about once a month or something like that. Though the take-up of things that have social networking power is immense because of the social aspect, I don't think that relatively unstructured applications that will be conducive to automatic generation of interfaces are going to be the interesting ones. The interesting ones are things like genealogy, home media library cataloguing, perhaps bibliography and so on.

There is an impasse here, therefore, if you consider that there should be one gigantic standard application for the Semantic Web.