W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

Re: Parameterized Inference - starting mail discussion

From: Bijan Parsia <bparsia@cs.manchester.ac.uk>
Date: Mon, 13 Apr 2009 20:21:28 +0100
Message-Id: <58F29AB7-2DCD-45CF-92E3-356E9863F3B0@cs.manchester.ac.uk>
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On 13 Apr 2009, at 19:29, Seaborne, Andy wrote:

> There seems to be an underlying tension here between the role and  
> responsibilities of the query and the role and responsibilities of  
> the data provider.
>
> A SPARQL endpoint provides access to data via the query language.   
> Different endpoints can have different datasets and different  
> inference regimes (using the existing BGP extension point).  The  
> data/service provider has a quite active role in determining the  
> facilities available and advertises these through a service  
> description.
>
> In the parameterized inference feature, it is the query (writer)  
> telling the general purpose query engine what to do.  The data and  
> service have a more passive role and the query writer is controlling  
> the whole process.

I think that's one reading, but it isn't necessary (though does seem  
to be presumed). After all we haven't really speced out what the  
server does in response to these directives. I do think most were  
thinking that an inference parameter was part of the semantics of the  
query, but one could interpret it more like conneg...for example, when  
querying a server that supported complete OWL reasoning, you might  
suggest which datasets weren't as important (by saying, "just RDF  
answers are ok here").

Contrariwise, we might let servers drop back to SPARQL with the  
standard entailment regime whenever they wanted to. Thus, the  
parameter specifies an upper bound on the answers.

>  This situation is more like important for building applications on  
> web data where there isnít split of service provider and information  
> consumer.

Seems like it could be useful when the provider and consumer are  
split, the provider can offer a variety of inference modes, and the  
client is able to provide useful information on preferred reasoning  
levels.

Of course, a server could provide distinct endpoints per reasoning  
level and the consumer could dispatch BGPs to the appropriate endpoint  
(doing algebra manipulations locally). This would be functionally  
equivalent.

Cheers,
Bijan.
Received on Monday, 13 April 2009 19:21:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:38 GMT