[Mulgara-dev] Re: Blank nodes in queries (was: Recent commits to Mulgara.)

Paul Gearon gearon at ieee.org
Sat Oct 7 04:43:18 UTC 2006


On Oct 6, 2006, at 9:42 PM, Andrae Muys wrote:
<snip/>
> We support
>
> * Transitivity - using an explicit trans() pattern-type, both  
> forward, and backward chained transitivity allow our users to  
> express memberof, subclassof, etc directly, without explicit rdfs  
> support required in the query engine.

I'd like to mention that we have forward and backward chaining, AND  
we have unchained transitivity.

Unchained transitivity is usually ignored, but it is useful for  
operations looking for entire groups across the store - and the  
complexity is still quite low (I have to look it up to give you the  
exact order, but it's pretty good).  One result is an ability to do  
transitive queries across the entire store.  For instance, using the  
unchained syntax:
select $s $p $o from <graph>
where $p <rdf:type> <owl:TransitiveProperty>
    and trans($s $p $o);

<snip/>
> * Pattern-Compliement - the exclude() pattern-type.  To be honest I  
> don't know why we need this.  When Paul and Andrew were working on  
> ensuring we could support RDFS/OWL they assured me it was required,  
> so I made sure I provided it.

Just to be clear here... I do NOT see the point in this operation.   
If I once argued for it, then I believe I was in error.  I do recall  
arguing with Andrew over the need for it, and my position then was  
that we do not.

My opinion on this may be different if RDF had negation as failure,  
but I'd have to consider this carefully before committing to that  
point of view.

> * Relational-Difference - the MINUS keyword.  Some of the rules in  
> RDFS are expressed in terms of excluding certain classes of term,  
> and the alternatives we faced were either an O(n) filter - or a O 
> (log n) difference.  Scalability is our top priority, only  
> correctness is more important to us.  So we added another  
> relational operator to our query language.

This is the required operation rather that the complement mentioned  
above.

<snip/>
> The only rationale referred to in the email you mentioned for  
> conflating blank-nodes with variables within a query is the desire  
> to express transitivity.  Specifically the desire to support the  
> RDFS concept of 'subclassof' within a SPARQL query.  The RDF- 
> Semantics document explicitly defines blank-nodes as skolem- 
> constants, ie. as existentials.  In this role they are doing an  
> excellent job, and my only complaint is that RDF has explicitly  
> restricted them to a first-order role --- in fact we are looking at  
> permitting second-order use within Mulagara, we anticipate rather  
> drastic simplification of various otherwise awkward modelling tasks.

I should comment that Mulgara was explicitly designed to be  
completely symmetrical about all elements of the assertions (subject,  
predicate, object, and even the graph).  From this perspective, it  
can support SOL as easily as FOL.  However, the interface used to  
refer to a "quad" places semantics on the positions within the  
statement.  So the first position is a SubjectNode and the third  
position is an ObjectNode, and both of these extend BlankNode.   
However, the second position is a PredicateNode, and this does NOT  
extend BlankNode.  So while the store can hold blank nodes (and  
literals!) in any position, and can easily search for them as well,  
when it comes time to return this data, the type system will report  
an error.  However, this constraint is artificial, and can be  
modified with ease.

> I simply don't believe Mulgara has had to face some of the issues  
> facing the DAWG because we chose to explicitly support transitivity  
> within iTQL.  There are two approaches I am aware of in supporting  
> transitivity
>
> 1. (our approach) support it directly within a query-pattern.  In  
> Mulgara "<s> <p> $y and trans(<s> <p> $y)" bind's to all objects  
> related to <s> within the transitive closure of <p>.  The simplest  
> syntax I have seen for this is actually to simply append a '*' to  
> the predicate, we like trans() because of our other pattern-types.

Actually, I never felt completely comfortable with our syntax, as it  
was not quite "intuitive" (whatever that is supposed to mean).   
However, it was the best I could come up with on the day.  I asked  
other people, but nobody had a better idea.  :-)

That said, it works well.

Regards,
Paul



More information about the Mulgara-dev mailing list