I agree that it is problematic to try to divide the query process into two stages, a "big" query that goes to a database server followed by an interactive exhibit browse of the results of the query. It means exhibit is hobbled because you can't use it to do a faceted browse over an entire database. We have discussed two good solutions to this problem:
1) recognize that exhibit already reflects a layering of a UI over a (currently javascript/json) database, and express that layering through an explicit API that can be implemented over a network. Clicking on a facet could result in a database call that travelled over the network API to a database which resolved it and sent back the data fitting the facet query; the client code would then use the exhibit templates to render that data. 2) host exhibits on servers, where large scale databases could be used to handle the data manipulation. For example, one could extend e.g. the longwell codebase (which already knows how to resolve faceted browsing queries) to use an exhibit template to display the results of the query. Of course, it would be great to define a single API which could then be used to support both of the ideas described here---you write the exhibit, it uses a local database server if available, otherwise it queries over the network. carmen wrote: > On Sat Mar 17, 2007 at 03:47:12PM -0500, Thomas Winningham wrote: > >> Keith, >> >> I've often thought that an Exhibit of an ad-hoc query or a specific RDF >> context is an insanely powerful and under used idea. >> > > the main problem is the dichotomy of 2 layers of querying. the initial > SPARQL/Versa/graph-pattern layer in the store. then the secondary layer in > the clientside/view-coupled store. > > when you sort by some category, maybe you would have interesting results that > arent in the local cache but are on the remote store - at this point, you > might as well throw away exhibit's database class completely, and replace it > with something that is designed from conception to work with multiple > endpoints/providers > > >> Its amazing to think of a query as setting the stage for further ad-hoc >> faceted analysis. This is almost the 2-part SPARQL query techniques to get >> to any view you want of RDF data as described by Danny Ayers in some of his >> blog posts. >> > > whats this? do you really think users want to think about their queries as > needing 2 parts? > _______________________________________________ > General mailing list > [email protected] > http://simile.mit.edu/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
