[Mulgara-general] Query from restricted graphs

Paul Gearon gearon at ieee.org
Wed Aug 23 17:19:09 UTC 2006


Hi Alexandre,

Sorry I didn't reply to this before now.  I've been busy on other stuff.

Yes, you can do what you want using "in" clauses (not "from").  See below...

On 8/23/06, Alexandre Passant <alex at passant.org> wrote:
> Hi all,
>
> I'm currently trying mulgura (never used kowari before), and got a
> question regarding 'from' queries.
>
> I'd like to retrieve information from a set of statements constraint
> with their properties.
>
> I first add all needed statements:
>
> create <rmi://192.168.0.1/server1#sampledata>;
> load <http://apassant.net/blog/sioc.php?type=post&id=104>
> into<rmi://192.168.0.1/server1#sampledata>;
> insert <http://apassant.net/blog/sioc.php?type=post&id=104> <dc:title>
> 'test graph' into <rmi://192.168.0.1/server1#sampledata>;
>
> I'm looking for something like
>
> select $s $p $o from $g where $s $p $o and $g <dc:title> 'test graph';
> (leads to Query Error: [1,22] expecting: '(', resource )
>
> Is there a way to do such queries ?

Yes.  Have a dummy "from" clause, and make $g you "in" clause:

select $s $p $o from <rmi://localhost/server1#>
where $s $p $o in $g
   and $g <dc:title> 'test graph' in $g;

I haven't tested this (I've never put the same variable in the
constraint and the in clause at the same time), but it SHOULD work.
:-)  Please report it as a bug if it doesn't and I'll get right on it!

> Finally, is there any difference between from and in ?

Not a lot, but there are a few things.

An "in" clause controls a single constraint can only contain a single
graph.  It over-rides whatever the "from" clause says.  So if you
don't have an "in" clause, then it defaults to the "from" expression.

The "from" clause can contain an "expression".  This is built from
unions and intersections of graphs.  Unions are performed with "or"
and intersections are with "and".  Because of the complexity of this
structure, you can't have variables here.

Internally, the expression in the "from" clause gets expanded into a
series of "in" clauses.   For instance:
  from <A> and (<B> or <C>)
  where $s $p $o;

gets transformed into:
  where $s $p $o in <A> and
     ($s $p $o in <B> or $s $p $o in <C>)

Of course, this expansion gets complex to read when expanding complex
"from" clauses against complex "where" clauses, but it's a fairly
straightforward algorithm, and it resolves efficiently.

So in a sense, the "from" clause is a shorthand for writing the same
constraints with a whole heap of "in" clauses.

There is one other difference.  The models named in the "from" clause
also tell the client library which address to find the server to issue
the query to.  The client takes the first model it finds, and sends
the whole query off to that server.  If there are other addresses in
the graph URLs then the server will complain.

For anyone interested, the server doesn't actually need to complain
here.  It is easy to fix in the simple case just by having the server
act a client for any constraints it has to pass on.  I once wrote an
implementation of this in a few hours.  However it's much more complex
if you want to be efficient with network bandwidth, etc.  :-)

Let me know how it goes.

Paul



More information about the Mulgara-general mailing list