- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Fri, 3 Jun 2005 13:54:25 -0400
- To: Dan Connolly <connolly@w3.org>
- Cc: public-rdf-dawg@w3.org
On Fri, Jun 03, 2005 at 12:21:45PM -0500, Dan Connolly wrote: > > Says who? Seriously, I don't like that contract, and I can think of others I > > like better. > > Do you have some other contract that you prefer? Or do you prefer > to just leave out the constraint that Yoshio and Andy are > advocating, and let the contract be unspecified? I would prefer to leave out the constraint. I don't believe that means that the contract has to be unspecified. I don't want there to be any surprises, but I also don't want there to be unecessary constraints. > Do you think it's OK (i.e. technically correct, if not high quality) > for a service to ignore FROM and FROM NAMED altogether? > Or is your > position that FROM and FROM NAMED be "lower bounds" > on the dataset used to service a query? Or something else? These are the cases I can think of, and what I prefer to happen in each case: 1. no RDF dataset specified in the query request: a. the service may either execute the query against its default RDF dataset; or b. it may return the QueryRequestRefused message. 2. RDF dataset specified in the query request, including both FROM and FROM NAMED graph(s): a. the service may either execute the query against the RDF dataset specified in the request; or a'. the service may execute the query against the RDF dataset specified but to which some process of inference has been applied; b. it may execute the query against the RDF dataset specified, but with the RDF merger of its default RDF dataset with the FROM graph(s) specified in the request; or b'. it may execute the query against the RDF dataset specified, but with the RDF merger of its default RDF dataset with the FROM graph(s) specified in the request, and to the results of which some process of inference has been applied; c. it may return the QueryRequestRefused message. 3. RDF dataset specified in the query request, including only FROM graph(s): same as (2). 4. RDF dataset specified in the query request, including only FROM NAMED graphs(s): same as (2). Obviously a crucial bit is communicating which strategy -- (a), (a'), (b), (b') -- a particular service is using. SADDLE would be ideal for that. I don't know how to communicate that right now, since we've punted on SADDLE. It could be communicated out of band, in the for-humans description of the service. And there's nothing preventing a service from deploying more than one endpoint, one of which uses one strategy, another of which uses the other one. The distinction I've been trying to draw between a service the sole point of which is to execute queries on behalf of requesters corresponds to (a); while a service that wants to publish a KB and execute queries against that KB and, perhaps, against other KBs corresponds to (b). Either of these kinds of service may employ some kind of inference, yielding the (a') and (b') strategies. Obviously if a requester doesn't fancy the strategy a service uses, it should ask a different service. Kendall Clark
Received on Friday, 3 June 2005 17:55:01 UTC