bc inferencing on optional query patterns

('binary' encoding is not supported, stored as-is)

Hi RDF-Interest, Hi Steve,

I'm developing an experimental store for smushing ifp resources, which
backs onto a relational database (similar to 3store).

I've been trying to implement backward-chaining subproperty
inferencing with BRQL-style optional query patterns, and am coming a
bit unstuck.

E.g. take the following query, which gets all http://example.com/foo's
props and objects, and if the object is a resource also gets an
rdfs:label for it:

select ?obj, objlabel
where    (<http://example.com/foo> ?prop ?obj)
OPTIONAL (?obj rdfs:label ?objlabel)

I want to do subproperty inferencing on the optional pattern to return
e.g. foaf:name labels (foaf:name is a subproperty of rdfs:label). 
As in the 3store paper[1], I am using the idiom:

?subj ?prop ?obj
-> 
?subj ?tmp ?obj
?tmp SUBPROPERTYOF ?prop


But that yields:

select ?obj, ?objlabel
where    (<http://example.com/foo> ?prop ?obj)
OPTIONAL (?obj ?tmp ?objlabel)
OPTIONAL (?tmp rdfs:subPropertyOf rdfs:label)

Which introduces a variable that exists only in the optional
clauses. I believe this makes the query un-deterministic - correct?
(it certainly doesnt work when it's translated into a relational sql
query with left-joins).  
N.B. this sort of query also isnt allowed by e.g. sesame.

So the only other solution is to do:
select ?obj, ?objlabel
where    (<http://example.com/foo> ?prop ?obj)
         (?tmp rdfs:subPropertyOf rdfs:label)
OPTIONAL (?obj ?tmp ?objlabel)
         
When this query evaluates, you get n*results where n is the number of
subproperties of rdfs:label. Most of these have 'NULL' values for the
objlabel (which correspond to subproperties of rdfs:label that don't
match a value).

i.e. I want:

?obj (?tmp)         ?objlabel
---------------------------
1234  foaf:name   "fred blogs"
2345  rdfs:label  "2345 label"


but I get:

?obj (?tmp)       ?objlabel
---------------------------
1234  rdfs:label  NULL
1234  foaf:name   "fred blogs"
1234  anotherprop NULL
2345  rdfs:label  "2345 label"
2345  foaf:name   NULL
2345  anotherprop NULL


This doesnt scale very well, as in a big store there will be *lots* of
subproperties of rdfs:label. Am I missing something obvious? How do
other stores tackle this problem?

Many thanks, 

Phil

[1]
http://km.aifb.uni-karlsruhe.de/ws/psss03/proceedings/harris-et-al.pdf