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

Seaborne, Andy andy.seaborne at hp.com
Fri Oct 6 17:27:31 UTC 2006


Congratulations to everyone on the progress and becoming more visible to
us lurkers.

> [] - introduces an implicit anonymous variable as the subject; useful
> when dealing with schemas (such as foaf) that use bnodes extensively.

The DAWG has been discussing this recently so your input would be very
timely.

Some systems, such as DL systems, wish to treat use blank nodes in
queries as non-distinguished variables - that is, they have no binding
to a graph term, nor might it be possible to find such a graph term.
The prototypical example is OWL disjunction where "A or B" is known to
be true but not which of the two it is.  Non-distinguished are necessary
to express some queries. See [1].

If a blank node is treated as purely and only existential, then it might
be that block nodes need different treatment to named variables.  On the
other hand, and certainly for access RDF graph with simple entailment,
it might be that systems are not forbidden in treating blank nodes in
queries as implicit anonymous variables with the same semantics as other
variables.

Test case:

Given data:

:x :p 1 .
:x :p 2 .

and SPARQL query:

SELECT ?x WHERE { ?x :p [] }

how many answers do you expect?

1?  Because as an existential, there is only one pattern match for :x :p
[] regardless of anything else in the query.

1?  Because, with set semantics to result sets, there is only one unique
answer?
    (this is permitted by SPARQL - but not mandated)

2?  Because the blank node can also be a universal and range over
possible matches where these can be determined as in the case here.

Either? Because the query didn't say DISTINCT so it's open to the
underlying engine's semantics.

Something else?


Compared with this query:

SELECT ?x WHERE { ?x :p ?y }

would you see this behaving the same as the blank node one (aside from
the actual number of results)?

The number of answers becomes more important on the way to counting and
aggregate functions (not that SPARQL has count() in any form):

SELECT count(*) WHERE { ?x rdf:type foaf:Person }
SELECT count(*) WHERE { [] rdf:type foaf:Person }


I'm interested in comments driven by implementation experience as well
as theoretical considerations.

	Hope that's reasonably clear,
	Andy

[1] http://daml.semanticweb.org/listarchive/joint-committee/0940.html


-------- Original Message --------
> From: Andrae Muys <>
> Date: 4 October 2006 07:24
> 
> This is just to let everyone know that both the compound-constraint
> syntax that was released in Netymon's Kowari repository a few months
> ago has been migrated and committed into Mulgara.  This syntactic
sugar
> is based on N3/SPARQL and allows the convenient manipulation of N-ary
> relations within an iTql query.    
> 
> For example to obtain the names of everyone with a relationship with
> 'Fred Jones', you can now use the following query: 
> 
> select $fname $lname from <model>
> where
> { $jones <firstName> 'Fred' : <lastName> 'Jones' } and [ <firstName>
> $fname : <lastName> $lname : <hasRelationshipWith> $jones ] ; 
> 
> This will be expanded into something similar to:
> 
> select $fname $lname from <model>
> where
> $jones <firstName> 'Fred' and
> $jones <lastName> 'Jones' and
> $__t1 <firstName> $fname and
> $__t1 <lastName> $lname and
> $__t1 <hasRelationshipWith> $jones ;
> 
> [] - introduces an implicit anonymous variable as the subject; useful
> when dealing with schemas (such as foaf) that use bnodes extensively.
> {} - allows the use of an explicit subject in a compound constraint. 
> 
> In a similar way to N3/SPARQL ':' is used to separate constraints with
> common subject; ',' to separate constraints with a common
> subject-predicate pair.  N3/SPARQL use ';' where we use ':', however
> ';' is already used in iTQL as a query terminator.   
> 
> See the documents under docs/design for further details.
> 
> I have also committed a change to the SymbolicTransformation SPI.
> This introduces a SymbolicTransformationContext parameter to all calls
> to transform.  This context permits the mapping of model URL's to
> model-type URI's.  This is essential if your transformer is to  
> distinguish constraints of potential interest to it's resolver.
> Supporting this, the Constraint interface now includes an explicit
> getModel() method.  All prior calls to getElement(3) (the previous
> implicit call to obtain the model), have been updated. 
> 
> Finally to complete the support for the introduction of custom
> constraints into a query (presumably via transformation), localization
> of constraints is now handled via the ConstraintLocalization
interface.
> 
> Andrae Muys
> 
> --
> Andrae Muys
> andrae at netymon.com
> Principal Mulgara Consultant
> Netymon Pty Ltd
> 
> 
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-dev



More information about the Mulgara-dev mailing list