Why protocol paramters should override the query in the specificiation of the dataset

Sometimes queries need to be directed to specific places.  For example, queries 
can provide custom RSS capabilities.  Find news items since some date; find news 
items about a particular subject area.  Many websites are database-backed so a 
RDF version using SPARQL to connect the application logic to a (web) database is 
a natural progression.

For testing on a different dataset, it is desirable to use exactly the same 
query but redirect it to the (temporary) URI of the new dataset being prepared. 
  Because the new dataset will be installed at the existing URI, there is no 
value in editing the query - it just increases the chance for errors.

Suppose a new dataset adds new features (new properties, say).  The website 
needs to make sure that the new features don't break the existing system. 
Running parts of the existing system against a new dataset (which will 
eventually be located at the same URI, replacing the old dataset) is needed. 
Changing the queries and changing them back again later is risky.


Conceptually, queries are templates for requests - not the requests themselves. 
  A query can be used several times (several requests). The protocol 
instantiates the query template into the actual request.


There are lots of ways of doing this - various ways of ad hoc parametrisation of 
queries, dynamically writing queries, additional levels of lookup for finding 
the target.  But having the protocol specified parameters for the dataset to 
override anything in the query does mean users can pass queries around, with a 
default target in them, and apply them unchanged to other datasets as well.

 Andy

Received on Thursday, 14 April 2005 10:55:46 UTC