Re: issues in rq25

* Eric Prud'hommeaux <eric@w3.org> [2007-01-23 13:44+0100]
> I am happy to be working with Andy's new draft, rq25. I've done an
> editing pass through the end of chapter 7. I have put my
> characteristic pink issue hilighter on a few points which I am
> describing here.
> 
> 
> 4.1.4 Syntax for Blank Nodes
> 
>   Blank nodes in query patterns act as *existential* variables.
> 
> I thought they acted as regular variables, i.e. one gets solutions for
> each way the bnode could match a different term in the graph.
> [TST] (below) tests this.
> 
>   The scope of the label is the basic graph pattern; if the same label
>   is used in another basic graph pattern graph pattern, it is not the
>   same blank node.
> 
> Is there really (still? again?) no correlation in the _:who variables
> in this query?
> 
> Data:
>   [ foaf:nick "ericP";
>     foaf:mboxMD5 "A2BA23432B434443D45DF655A6C6E6E" ].
>   [ foaf:name "Bob Smith";
>     foaf:mbox <mailto:bob@example.com> ].
> 
> Query:
>   SELECT ?nick ?mbox
>    WHERE { _:who foaf:mboxMD5 "A2BA23432B434443D45DF655A6C6E6E";
>      foaf:nick ?nick
>     OPTIONAL { _:who foaf:mbox ?mbox } }
> 
> Results:
>   ?name  ?mbox
>   ericP  <mailto:bob@example.com>

Andy proposed in the meeting to make this misleading query (in that it
associates ericP's name with Bob Smith's mbox) illegal by prohibiting
the re-use of BNodes between different BGPs. The cost is to the person
who does a SELECT * and then limits their returned fields by
judiciously using BNodes for the fields they don't want to see. Not a
big cost.

The motivation is to make the semantics of BNodes in BGPs an extension
point, probably most useful to the DL community, who I believe use them
as existentials whose co-refs they don't have to find.  Experimenting
with Pellet [PL], I note that it *does* treat blank nodes as
existentials:

Using the data and query from bnode-type-var [BTV], we expect (at
least):
  <http://www.mindswap.org/2003/owl/mindswap#Programmer>
  <http://xmlns.com/foaf/0.1/Person>
  <http://xmlns.com/foaf/0.1/Person>
  <http://www.mindswap.org/2003/owl/mindswap#Researcher>
  <http://xmlns.com/foaf/0.1/Person>
  <http://xmlns.com/foaf/0.1/Person>
  <http://xmlns.com/foaf/0.1/Person>

but we get [PRS]:
  owl:Class
  owl:ObjectProperty
  rdf:Property
  owl:Thing
  foaf:Person
  mindswap:Programmer
  mindswap:Researcher

owl:Class, owl:ObjectProperty, rdf:Property and owl:Thing are all
inferred. Without that inference, we get
  foaf:Person
  mindswap:Programmer
  mindswap:Researcher
which is consistent with what algae gives me when I tell it to treat
blank nodes as existentials:

./algae --bnode-is-ext -i n3 -d rdfSemantics/data-se-foaf.ttl -f rdfSemantics/query-se-bNode-type-var.rq
┌──────────────────────────────────────────────────────┐
│                                                  type│
├──────────────────────────────────────────────────────┤
│                    <http://xmlns.com/foaf/0.1/Person>│
│<http://www.mindswap.org/2003/owl/mindswap#Programmer>│
│<http://www.mindswap.org/2003/owl/mindswap#Researcher>│
└──────────────────────────────────────────────────────┘*
* only coincidentally reduced to the same thing as DISTINCT.

Pat, Andy, does this resonate with your understanding of what would
serve the DL folks?

If this is correct, I am actually quite in favor of making bnodes be not
only scoped to the BGP, but also existentials. That would give them some
use to the non-DL folks (uses for EXISTS in SQL abound), and improve our
odds at serving the DL folks.


[PL] http://www.mindswap.org/2003/pellet/demo.shtml
[PRS] http://w3.org/brief/MjI=
[BTV] http://www.w3.org/2001/sw/DataAccess/tests/#rdfsemantics-bnode-type-var


> 5.1 Group Graph Pattern
> 
>   For any solution, the same variable is given the same value
>   everywhere in the set of graph patterns making up the group graph
>   pattern.
> 
> We had a WG decision on this and I want to make sure the spec lines up
> with that.
> 
> 
> 5.3 Order of Evaluation
> 
>   There is no implied order of graph patterns within a Group Graph
>   Pattern
> 
> This is the full-outer-join issue. How did this get resolved?
> 
> 
> 7 Matching Alternatives
> 
>   Query results involving a pattern containing GP1 and GP2 will
>   include separate solutions for each match where GP1 and GP2 give
>   rise to *different* sets of bindings.
> 
> We talked about this some, too. Can't remember where we got. I prefer
> to not have an implicit DISTINCT on UNION (something the SQL folks
> regret).
> 
> 
> I have some notes to add examples:
>   empty graph patterns:
>     WHERE { OPTIONAL { <mumble> <foo> ?bar } }
>   FILTERs outside of the binding OPTIONAL:
>     OPTIONAL { <mumble> <foo> ?bar } FILTER (!BOUND(?bar) || ?bar < 5) }
> 
> I'd like to clarify whether qname expansion occurs *before* relative
> IRI resolution. Does
>   BASE <http://example.org/services/SPARQL>
>   PREFIX foo: <../namespaces/foo#>
>   ... WERE { ... foo:barw ... }
> mean
>   <http://example.org/namespaces/foo#bar>
> ?
> 
> 
> I'm not convinced that 4.1.4 Syntax for Blank Nodes needs to go into
> such detail on the [ :p :o ] syntax, which is later described in
> 4.2.1. It's tough, you kinda need to teach these things in parallel,
> and it's tedious to teach them non-exhaustively and later define them
> exhaustively. I don't have any better ideas.
> 
> 
> Tx a zillion for all the fab work, AndyS!
> 
> 
> [TST] http://www.w3.org/2001/sw/DataAccess/tests/#rdfsemantics-bnode-type-var
> -- 
> -eric
> 
> office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
> cell:   +1.857.222.5741
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.



-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.