[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