Re: Comments on "SPARQL Query Language for RDF"

Trying to go back and catch up on earlier email in case it proves 
useful.
On Sep 3, 2005, at 12:52 PM, Enrico Franconi wrote:

> 1) On 2 Sep 2005, at 12:58, Seaborne, Andy wrote
> <http://www.w3.org/mid/43183071.1070508@hp.com>:
>
> > = subgraph / entailment
> >
> > The RDF MT defines three kinds of entailment - simple, RDF and RDFS.
> > RDF and RDFS are examples of vocabulary entailment.
> >
> > SPARQL basic patterns are defined to match by subgraph - the graph
> > being matched against contains RDF and can have some level of
> > entailment applied or not.
> Your first example misses this because
> > you show the data, without a declaration of the entailment to be
> > applied.  The SPARQL query can execute against a simple entailed
> > version or RDF entailed version (or "zero entailment").

Where is this specified? Just trying to get a handle.

Hmm. Re: infinite solutions...it seems like Enrico is endorsing that 
overall, given rdf:_1 etc. That is, there is an infinite number of 
axiomatic triples, so you have to add all of them to an RDF entailment 
closed virtual graph.

> OK, then it is necessary to change:
>
> s/subgraph of/entailed by/ in defn of basic pattern
> (we have noticed that this change has been done already twice...)
>
> and somewhere there should be the ability to declare the type of
> entailment (simple, RDF, RDFS - as defined in RDF-MT).

RDFS is out of scope (alasly). But it should be easy once one of these 
solutions falls into place.

> ======
>
> 2) On 2 Sep 2005, at 12:58, Seaborne, Andy wrote
> <http://www.w3.org/mid/43183071.1070508@hp.com>:
>
> > = Blank Nodes in query results
> >
> > Blank nodes as distinguished variables can't be returned in SELECT
> > queries. This is by design.  An application should use a named
> > variable if it wants to return the binding in a solution.
>
> Uhu? We said "Blank nodes as binding of distinguished variables",
> which are clearly allowed (see, e.g., the example
> <http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050721/#BlankNodes>).
>
> So, the problem we mention in the comments remains:
> the minimality of answers is not guaranteed, since tuples in the
> answer set may be redundant.
> In our example we show how two equivalent graphs (i.e., they entail
> each other) give different answers to the same query. This is due to
> the fact that minimality is not required.

Hmmmmmmmm. maybe not true on the deductive closure model? Yeah, since 
they entail each other and you throw in all the entailments. Instead of 
one answer, you get a whole lotta.

Perhaps we can recover minimality by some sort of fixpoint on the 
answer set? If the answers differ only by...entailed bnodes? No. hmm. 
Ick. Skolemize? It's tooooooo laaaaate.

If one is trying to query the "document structure" then the first and 
second of your examples, though equivalent, should be different, right? 
I mean, one has two triples and the other one just one. (ick)

Also, there are use cases (foaf and OWL-DL ontologies structure) that 
make heavy use of BNodes in..well...perhaps not exactly kosher ways. 
Hmm. Foaf may not be as bad if you just make the subject of the type 
Person triple always undistinguished. I guess there are workable design 
patterns, but I have to check with my portal people.

> We need to enforce in the definition the minimality of answers. This
> may happen if there are bnodes in the result (and \top unbound nodes
> in the result - see below).  This can be easily and efficiently
> implemented (e.g., just hash the bnodes in the answer whenever you get
> them, and check).

I need this expanded.

Cheers,
Bijan.

Received on Wednesday, 7 September 2005 06:42:58 UTC