Re: subgraph/entailment

On Wed, 2005-09-07 at 09:49 -0400, 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).

That's my understanding of the LC SPARQL QL spec, yes.

>  There are some hitches to work out and it 
> should be clearly explained in the document.

I can imagine making it more clear, but I'm not inspired with any
words. I think I have been staring at the document waaay too long.

> >>> 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?

We haven't made a distinction between normative and informative
sections.

So in one sense, yes, it's normative since we didn't say otherwise.

In another sense, it doesn't actually contribute any formal constraints
to the specification of the language. Strictly speaking, it could be
deleted without changing the meaning of the specification. So in
that sense, it's informative. It just says how this language relates
to other things that we expect the reader might be familiar with.


> > 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".

Yes.

> > [...]
> >>
> >> 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?

Apparently, I answered a question other than the one you meant to ask.

The definition of SPARQL relates an RDF graph (well, actually,
a dataset, which may involve more than one graph) and a query
to some solutions, and the query is specified to match against
that RDF graph rather literally.

> >> 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.

The spec is intended to be consistent with 3Store; it's evidently
insufficiently clear.


> >  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).

If we had a finished SADDLE design, sparql.org could advertise
whether their dataset is the raw RDF graph or includes axiomatic
and inferred triples. As it is, you'll just have to rely on prose
READMEs or chat with Andy (or better yet... some experimental
SADDLE-like thing). Likewise librdf/DaveB.

>  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.
[...]

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 7 September 2005 14:12:21 UTC