[Mulgara-dev] Recent commits to Mulgara.

[Andrae Muys]

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