Re: subgraph/entailment

On 7 Sep 2005, at 02:13, Bijan Parsia wrote:
> Let me try to proxy pat for a moment. (Actually, I don't believe  
> any of this is in the spec, so maybe it's a useful exercise).
>
> So, what counts as a "completion" of this graph wrt the OWL Lite  
> consequence relation? If we think that the completion should be,  
> roughly, something corresponding to an interpretation (actually a  
> model), then while in every model Paul *will* be q, the *way* he  
> will be q will be different. In some models, Andrea is an employee,  
> and since she's friends with Caroline the manager, Paul's in. When  
> Andrea is *not* an employee (she could be either, but must be one),  
> she is friends with Simon the employee friend of Paul. So Paul is  
> still in. So, if we think the completion of the RDF graph has to  
> correspond to an interpreation like that (which is VERY  
> PLAUSIBLE!!!!), then the subgraph of a completion of the graph (or  
> *the virtual graph*) is bankrupt. I so argued this at the tech  
> plenary.

Correct.

> The other way is to ask whether *the formula*
>     some(Y)some(Z)(worker(paul), has-friend(Paul, Y), has-friend(Y,  
> Z), manager(Z)
> is in the deductive closure of the above ontology? Clearly yes. So,  
> if I want to SPARQL query this ontology what must I do  
> (conceptually, not practically)?
>
>     1) Add *all* the (infinite) consequences to the set
>         Note that these *won't* be concrete interpretations but  
> have lots of existential and         disjunctive formulae,
>     2) Take those formula and serialize them in RDF a la the  
> reverse of the transformation to
>         triples table in the OWL Semantics and Abstract Syntax
>         NOTE! This means you can't query FOL or have an FOL strong  
> query language,         if the transformation has to be a same  
> syntax semantic extension (see PFPS's
>         ichai paper) While not harmful for OWL, it does seem to be  
> a deal
>         NOTE! This puts a HUGE burden on SPARQLOWL folks. I mean,  
> for example,
>         do I interpret the syntax triples according to OWL FULL?  
> Ok, the answer for me
>         is no, but it's seems  to be a minefield
>     3) Match the subgraph on this extension
>         NOTE! I've not worked out that this will *actually work*  
> given the definitions
>         It might not if the syntax doesn't *match exactly*.

Aha, then SPARQL computes the subgraph over the infinite *deductive  
closure* of the original RDF graph, and not only over one completion.  
Now I see it. Of course, in the case of RDF, since it enjoys the  
minimal model property, there is only one (finite) completion, and  
this coincides with the deductive closure. That's why the problem  
didn't show up if we just have RDF. Thanks for this clarification!

>> So, if you want to allow SPARQL to handle in the future such  
>> (simple) cases like this, where you have (simple) RDF-based  
>> ontologies together with plain RDF data, you have to drop the  
>> notion of subgraph and resort to entailment. Please note that  
>> these cases are already well understood, implemented, and tools  
>> are available. By limiting SPARQL now, we will tell the ontology  
>> community to use another query language for anything than RDF (and  
>> possibly RDFS), while SPARQL would be a natural candidate for any  
>> RDF-based ontology language (like, e.g., OWL-DL).
>
> Now this I buy :)
>
> So, all argument here is future looking. We all agree we can handle  
> RDF and RDFS with this wording. In a sense, that may satisfy the  
> charter, but I think squeaking by on the charter is a real mistake.  
> I don't believe the working group AS A WHOLE made an informed  
> decision. Indeed, the history is *understandably* deferring to the  
> last expert who didn't give up :)
>
> However, that's not a good way forward (which is unfortunate, since  
> I'm on the side of the current expert :)). However, I've talked to  
> a number of experts and rising experts (Ian Horrocks, PFPS, Boris  
> Motik, Birte Glimm, Jordan Katz, Enrico, Bernardo Grau, etc.).  
> Plus, this isn't the "DL" way of doing things, but the standard way  
> to specify a query language. Why add to the conceptual load? Esp.  
> if the argument is that it *simplifies* the specification!!!! Even  
> if it does in some abstract way, it does so with a HUGE, easy to  
> misunderstand deviance from standard practice (afaict).

I agree with you, of course, since I have been yet another victim of  
this misunderstanding :-)

cheers
--e.

Received on Wednesday, 7 September 2005 00:25:24 UTC