On Tue, 26 Jun 2007 06:15:07 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > Exhibit is now coupled with Babel, a RESTful web > RDFfization web service that we run so that it can do conversion on the > fly. >
I think this is really cool btw, and makes Exhibit a much more attractive proposition in a wider variety of cases. Anyway - the problem is that you want to be able to create a page that: * shows the same data to google and the javascriptless as to the javascript enabled browser. * easy to maintain * not place too many additional technical burdens on the average professor who wants to list his publications (as the target user) # js-based html importers I think Johan has produced the closest solution to this with his html table importer - the database link is to a fragment of the current page, and his importer hides that fragment, so that only the Exhibit is visible, and not the table. I think my RDFa and eRDF importers should do this too - if the link href is a local fragment, then hide the element of that id. However, I think an html table of data is, in most cases, easier for the average professor to maintain. The disadvantage is that html can be a clunky format to maintain medium-large quantities of raw data in. # local server-side solution Store the data in a more lightweight format like JSON or CSV, and use a server-side script to parse it into HTML. This HTML can have a javascript redirect to the Exhibit. So Google indexes the HTML file, the visitor follows the link to it, and is redirected straight away to the Exhibit. The professor doesn't need to write or edit the server side script - you can give him a generic one that accepts local filenames as a GET parameter. (I posted a simple version of such a script in PHP to this list a while ago). The disadvantage is that the professor needs to be able to run server-side scripts, and know a little bit about his server environment (which languages it supports etc); moreover, he doesn't control the appearance of the pure HTML version, which is generically generated. # remote server-side solution Simile could host a service (yet another one) that lets the professor link to it providing his data location and exhibit location. This service would do the same as the previous solution - generate a generic HTML version of the data, and provide a javascript redirect back to the Exhibit. The disadvantage is that the experience is still inferior for the javascriptless human. I can suggest one more solution that allows separation of data and presentation, and allows control over both the javascripted and the javasscriptless presentations, but I fear it may raise the technical bar slightly beyond the reach of our target professor. You might remember a post I made about using eRDF for server-side templating a while ago; I've evolved the idea a bit, and stuck some code up at http://code.google.com/p/erdf-t/ The idea is basically to use RDF's self-describing nature to make templating easier. You write a template which (like exhibit) uses <link>s to point to the data file the template uses. You can then access the data within the template in two ways: 1. an associative array of resources 2. using eRDF to describe the value of variables It requires PHP5 to run, but not a great deal in the way of programming skill, as all you are doing is writing templates. So, you could conceivably store your data in TSV, use babel to convert it to RDF/XML and Exhibit JSON on the fly for consumption by your PHP template and your Exhibit - and the PHP template could contain a javascript redirect to the Exhibit, or could contain the exhibit itself (the exhibit could then run off of any of eRDF, RDFa, html tables, or straight from the TSV), hiding it with javascript. Not an ideal solution for this specific problem I admit, but perhaps of some interest to some people here. Yours, Keith _______________________________________________ General mailing list General@simile.mit.edu http://simile.mit.edu/mailman/listinfo/general
