Re: Name of a graph? and FROM and FROM NAMED

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