[Mulgara-general] Query from restricted graphs

Thu Aug 24 15:11:55 UTC 2006

I've been doing some playing around with this, with not too much
success.

Assumptions:
- named graphs are Mulgara models
- assertions can be made about the graphs by using the Mulgara model URL
(URI?) as the subject of the assertion (triple)
- queries can then be made, for instance a "where" clause determining
what graph (model) to use and then using this (variable) in an "in"
clause (after a second "where" clause)

Based on the above, I think Alex's insert statement needs changing in
two ways.  At the moment, it results in the following triple, in the
#sampledata model
[<http://apassant.net/blog/sioc.php?type=post&id=104>, <dc:title>, 'test
graph']

a) the assertion doesn't have the #sampledata model as the subject, it
has the original source of the data (though of course it would be valid
to add a triple saying what the source of the data was, eg
[<...#sampledata>, <my-ns:hasSource>, <http://to.the.source/url>]

b) I don't think this triple should live in the same graph as the graph
itself -- wouldn't it be more sensible to have this in a separate graph?

To cover point (a) above it's necessary to know what URL or URI to use
to identify the Mulgara model (and hence the named graph) which brings
me to...

My findings on trying to get this sort of thing working:
1) it is possible to have a variable in an "in" clause, for example the
following works:

select $s $p $o from <rmi://localhost/server1#> where $s $p $o in $g and
$g <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://mulgara.org/mulgara#Model>;

2) specifying the model URI directly does not work, for example neither
of the following work:

select $s $p $o $g from <rmi://localhost/server1#> where $s $p $o in $g
and $g <tucana:is> <rmi://rcdevs003.Rightscom.local/server1#sampledata>;

select $s $p $o $g from <rmi://localhost/server1#> where $s $p $o in $g
and $g <tucana:is> <rmi://localhost/server1#sampledata>;

Mulgara 1.0.0 doesn't seem to have the URLMapperResolver implemented,
which *may* help here -- to return the Model URI and use that in the
above (instead of URLs dependent on machine names).  I'm not sure.

So the crux of the issue at the moment seems to be how to correctly
express the identity of a Mulgara model (in both a triple, so assertions
can be made about it; and in a query).

Maybe this can be done already?  None of the variations I used worked.

As an aside, I did also try the above using Kowari 1.2.0, which does
have the URLMapperResolver, but queries such as the first one above
resulted in errors like:

Couldn't answer select query.

Error resolving [$s $p $o $g] from null

Caused by: (QueryException) Expecting predicate:
http://tucana.org/tucana#hasURL or hasCanonicalURL for
org.kowari.resolver.urlmapper.URLMapperResolver

org.kowari.query.QueryException: Error ending previous query

Regards
Steve

-----Original Message-----
From: mulgara-general-bounces at mulgara.org
[mailto:mulgara-general-bounces at mulgara.org] On Behalf Of Paul Gearon
Sent: 23 August 2006 18:19
To: Alexandre Passant
Cc: mulgara-general at mulgara.org
Subject: Re: [Mulgara-general] Query from restricted graphs

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
_______________________________________________
Mulgara-general mailing list
Mulgara-general at mulgara.org
http://mulgara.org/mailman/listinfo/mulgara-general