Re: Signalling entailment in queries

On Jul 20, 2010, at 5:37 PM, Sandro Hawke wrote:

>> I've always considered it a feature that an endpoint could use entailment on the underlying data and the user would use the same query syntax. I'd be very hesitant about a syntax that requires the user to specify an entailment regime to use, especially if the system only supports one entailment regime and will throw an error if you request others. I don't want to be in the position of trying to submit a query by hand and having to guess the supported entailment repeatedly or having to download the service description and pick through it to figure out what entailment regime the endpoint supports.
> 
> I think I don't understand how you expect inference to be used in
> SPARQL.  Can you give me a quick sketch or two?

My understanding was that entailment may be used with either the entire dataset or per graph, but that the decision of what and when entailment is to be used is up to the endpoint. I thought we specifically decided not to pursue parameterized inference, so the design of the entailment terms in the service description was intended to reflect this. The recent discussion seems to be talking about parameterized inference again, and I think that issue has to be settled before we can make sensible decisions about what the service description is meant to be describing.

> As for needing trial-and-error to find the right entailment -- (1)
> that's exactly what SD is for, right? and (2) that's why I want
> un-parameterized entailment -- for the case where the end point has
> exactly one logic it's happy with.

Right. I thought (1) was off limits, but (2) is what we've been discussing.

Of course, this leaves open the issue of naming of named graphs that have entailment... I'm still not sure how your suggestion of renaming graphs with entailment would work out in practice in a lot of implementations.

.greg

Received on Saturday, 31 July 2010 19:18:25 UTC