Re: Signalling entailment in queries

"Gregory Williams" <greg@evilfunhouse.com> wrote:

>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

I withdrew the 'renaming' proposal when I was reminded that in many entailment regimes (eg ones with disjunction) there is not a graph that sensibly contains all the entailments.

I suggested parameterizing the inference in the query would make sense, but Kendall didn't like that, and it's quite possibly out of scope.

My concern then returns to whether SD for ER makes sense.  Kendall says pellet server has its own SD they are happy with, for ER, so that makes me fairly optimistic.   Probably the SD modeling following on the update modeling (cf friday's telecon) will help.  I would like to make sure its described in a way that doesn't rule out parameterized inference.   So, something like 'the default ER for queries on graph G and endpoint EP is E.   So, it's a ternary relation.   I guess the leading approach to those is to reify them, coming up with a name for the relationship.  Perhaps an EntailmentBinding, which has three properties: endpoint, graph, and entailmentRegime.   This is for the named graphs, and the term graph is meant to be understood in that 'slot' sense.

   - sandro  
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Received on Sunday, 1 August 2010 19:29:42 UTC