Re: subgraph/entailment

Bijan Parsia wrote:
> On Sep 7, 2005, at 9:19 AM, Dan Connolly wrote:
> 
> 
>>On Tue, 2005-09-06 at 23:35 -0400, Bijan Parsia wrote:
>>
>>>On Sep 6, 2005, at 10:35 PM, Dan Connolly wrote:
>>>
>>>
>>>>On Wed, 2005-09-07 at 03:47 +0200, Enrico Franconi wrote:
>>>>[...]
>>>>
>>>>>Now we have three possibilities:
>>>>
>>>>I'm getting lost.
>>>
>>>To pick up the dialectic as I understand it, Enrico thought (as many 
>>>do
>>>on first reading) that the subgraph language *precluded* extending
>>>SPARQL to query datasets expressed in more expressive logics than
>>>RDF/RDFS (while respecting the semantics of those logics).
>>
>>Yes, as designed, it does. The way more expressive logics fit into
>>this design is that they contribute to the graph that's being
>>queried against...
> 
> 
> Yes but it's *how* they do so that's at issue. I take it you endorse 
> the second strategy (query the triple encoding of the deductive closure 
> of the original theory). There are some hitches to work out and it 
> should be clearly explained in the document.
> 
> 
>>>>It's already possible for a server to chose the deductive closure
>>>>of the original information as its background graph.
>>>
>>>Pointer please?
>>
>>"These triples can come from a variety of sources. For instance, they
>>may come directly from an RDF document. They may be inferred from other
>>RDF triples."
>> -- http://www.w3.org/TR/rdf-sparql-query/#introduction
> 
> 
> Is that section normative?
> 
> 
>>See also our discussion of serviceDescription; i.e. ways that a
>>server can advertise what dataset it uses...
>>  http://www.w3.org/2001/sw/DataAccess/issues#serviceDescription
>>
>>We decided that's not ready for standardization just yet.
> 
> 
> You mean serviceDescription, not querying "virtual graphs".
> 
> 
>>[...]
>>
>>>Er...so SPARQL is defined only for RDF graphs without their semantics?
>>>Or, rather, only against the *asserted* triples in an RDF graph?
>>
>>Yes.
> 
> 
> You really don't mean this, right?
> 
> 
>>>This isn't happy!
>>
>>We have a growing body of experience that says it's happy enough for 
>>v1;
> 
> 
> I think it's unhappy if it precludes, contra to what seems to be 
> people's beliefs, extension to stores with RDF, RDFS, and OWL 
> semantics. Right now, in spite of the prose in the intro, it is unclear
> 
> 
>>the design meets all the WG's requirements do date; 4 or 5
>>implementors have coded up this design without complaint,
> 
> 
> If 3Store (with RDFS inferences always on) is a non-compliant system, I 
> think Steve would complain :) I'm not clear that it is, but I'm not 
> clear that it isn't given the current spec wording.
> 
> 
>> and a
>>modest number of fielded services seem to meet user expectations.
>>
>>http://esw.w3.org/topic/SparqlImplementations
>>http://esw.w3.org/topic/DawgShows
> 
> 
> Plain RDF entailment may be uninteresting, but I think Enrico's point 
> is well taken.
> 
> I tried this query:
> 	PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
> 	SELECT ?p
> 	WHERE {  ?p rdf:type rdf:Property }
> 
> in http://sparql.org/query.html and http://librdf.org/query and got no 
> hits. I think I could have reasonably expected to have gotten all the 
> asserted properties in the document (by entailment rule rdf1).

Which model did you query?  Did you read the service description as to what 
the contract on that service with that model is?  Where does it say it gives 
simple/RDF/RDFS entailment?

> I would 
> have perhaps been surprised to have gotten all the properites in the 
> axiomatic triples, but probably would have concluded that that was 
> correct. As an implementor, I would have thought, reading the specs, 
> that both the above implementions got it wrong because my understanding 
> of a proper RDF graph *for the purpose of query* would have including 
> the entailments forced by the semantics.

Ah - you are saying that there should never be "zero-entailement".
and you also say that you expected some and not others.

You do need to check the service description to see what the service offers.
(which is tricky for http://sparql.org/query.html :-)

	Andy

> 
> 
>>>Of course, you could just restrict yourself to asserted triples. My 
>>>org
>>>will probably object, though.
>>
>>We have already restricted ourselves to asserted triples.
> 
> 
> I mean "asserted in the document", not "asserted as a result of 
> inference".
> 
> 
>>Your org already agreed to the present design.
> 
> 
> No, afaik, since there are two readings.
> 
> 
>> There are probably
>>other relevant decisions that you're party to, but the recorded
>>decision that's easiest for me to find is when we decided, 28 June,
>>to go to last call.
>> http://www.w3.org/2005/06/28-dawg-minutes#item09
>>
>>There is perhaps new information that motivates reconsidering
>>the design. Perhaps you could elaborate on "This isn't happy."
> 
> 
> I don't think the current spec clearly says whether you *have* to ONLY 
> query "base" triples (maybe base vs. inferred is clearer than asserted 
> or not?).
> 
> That *really* isn't happy, IMHO. There's a clear sense in which it is 
> hard to claim that SPARQL is an *RDF* query language if you *cannot* 
> query an RDF graph with RDF semantics.
> 
> I *think* this is just an underspecification/unclarity bug.
> 
> 
>>[...]
>>
>>
>>
>>
>>>Have we met the charter if we can't query (or have runaway bad query)
>>>for graphs closed under RDF entailment?
>>
>>I suggest we leave the charter aside for a bit.
> 
> 
> You raised it. I'm happy to set it aside.
> 
> 
>> If a critical mass
>>of the WG supports some new requirements, and those requirements
>>conflict with the charter, we'll look at ways to resolve that conflict,
>>including modifying the charter.
> 
> 
> Cool.
> 
> Cheers,
> Bijan.
> 
>

Received on Wednesday, 7 September 2005 14:37:18 UTC