- From: Phil Dawes <pdawes@users.sourceforge.net>
- Date: Thu, 1 Apr 2004 16:54:21 +0100
- To: www-rdf-interest@w3.org
Hi All, I've been involved in developing 5 RDF applications to date, and in each I've found that the same architectural pattern emerges each time: - Application has an in-memory rdf store(s), which it manages and accesses via simple fine-grained API. (sortof the M in MVC) - A number of larger RDF sources/stores exist, which contain information useful to the application. - Application performs remote queries on the larger RDF sources, and inserts/merges the results into its local rdf store(s). - Application uses simpler fine-grained api to walk the internal store(s) whilst performing application logic (rendering UI etc..) This is the case even for web-applications with a stateless middle tier (i.e. an internal rdf model is built up on each request). The reason that I'm writing is that in order to facilitate this style of architecture, ideally the larger rdf stores need to support returning query results as an rdf graph (sometimes a specially constructed rdf graph). As far as I can see, only Sesame directly supports this (via its seRQL construct query), which confuses me. Is this an uncommon approach? Are there disadvantages to this approach compared to using a query result format that binds variables to result values (e.g. rdql)? Many thanks, Phil
Received on Thursday, 1 April 2004 13:49:04 UTC