[Mulgara-dev] ITQL

[Alex Hall]

Coming in a bit late on this conversation, but let me add my 2 cents 
worth...

Paul Gearon wrote:
> On Sat, Jul 12, 2008 at 5:53 PM, Life is hard, and then you die
> <ronald at innovation.ch> wrote:
>> I understand that we're querying over an open-world, and I'm perfectly
>> fine with statements being returned that weren't explicitly entered,
>> and I'm fine with the "implicit" graph.
>>
>> My issue that is we're and'ing two contraints, and a conjunction of A
>> and B usually returns less than (or same as) A, not more, i.e.
>> A ⊆ A ⋂ B, for all B.

I see Ronald's point here.  IMHO, the main point of contention is that 
Paul's example of:

SELECT ?x ?y
WHERE { ?x <ns:ancestorOf> ?y .
         <ns:ancestorOf> <rdf:type> <mulgara:TransitivePredicate> }

is overloading the constraint mechanism to add information to the graph 
as opposed to constraining it.  If we're going to strictly follow the 
semantics of a constraint expression in the where-clause, the constraint 
"<ns:ancestorOf> <rdf:type> <mulgara:TransitivePredicate>" should be 
*testing* whether ancestorOf is a transitive predicate.  Instead, this 
example uses the constraint to *assert* that it is a transitive 
predicate.  Constraints with no variables should be tests, not assertions.

Setting aside the semantics of the where-clause and interpretations of 
infinite graphs, another important point is that executing the above 
query against the same graph residing in a store that doesn't know about 
mulgara:TransitiveConstraint will result in an empty result set. 
Ideally, an implementation of trans for SPARQL would allow non-Mulgara 
stores to return the original base statements when presented with the 
same query.  I suppose this could be worked around by using an optional 
join, but that would add complexity to the query transformation code.

> My point is that you're never seeing all the possible results. A lot
> of the extrinsic possible results are never shown, usually because
> there's not enough context to know which are valid for you. By
> constraining things more, then the possible results go from "infinite"
> down to "another infinite" that's smaller than the first one. The
> difference here is that the smaller result set contains more valid
> statements ("valid" means "true in all interpretations"), so you're
> able to return a larger set. I guess it's an irony that you have more
> valid statements when the number of consistent statements is reduced.
> :-)

The constraint <ns:ancestorOf> <rdf:type> <mulgara:TransitivePredicate> 
will resolve to either empty or unconstrained, meaning that it will not 
help you "narrow down" the contents of an infinite graph; it will allow 
you to select the infinite graph that contains the results you are 
interested in.  At least, according to my (admittedly rusty) 
recollection of the semantics of infinite graphs and interpretations.

I think that a more appropriate idiom for expressing a query for a 
transitive relationship would be to introduce a "given" clause, i.e.:

SELECT ?x ?y
WHERE { ?x <ns:ancestorOf> ?y }
GIVEN { <ns:ancestorOf> <rdf:type> <mulgara:TranstivePredicate> }

In other words, you want to create a new graph that is the union of your 
base graph and the contents of the GIVEN clause and query over that.

Having said all that, I think that Paul's proposal is the most 
straightforward option for implementing trans and walk for SPARQL 
queries in Mulgara.  We'll just have to live with the weird semantics 
and the possible incompatibility with other stores.

Alex