[Mulgara-general] Query from restricted graphs

[Stephen Bayliss]

Hi Paul

Thanks for your reply.  I've tried your suggestions (with some
success!), my comments inline.  

And by the way, excellent news on this new release, I was having a quick
play with krules earlier, glad to see that it is in this release!

> > 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?
>
> I think so, yes, but it shouldn't be a big deal.

Agreed, this depends really on the overall information model.

> That's because the "localhost" got converted to what the system
> believes is the "canonical name" for the server.  To see what the real
> URL is, have a look at the contents of <rmi://localhost/server1#>.

Solved it!  I had in fact tried with the canonical name, but I was using
<mulgara:is> (actually originally I was using <tucana:is>).  Changing
this to <http://mulgara.org/mulgara#is> is returning results!

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

I'm now going to try an example where the model name is looked up using
a predicate and a literal.

> > 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
>
> Is this the query:
> 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>;

Nearly... It's Kowari not Mulgara (1.2.0), so it is:

iTQL> 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://tucana.org/tucana#Model>;
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


> 
> ???
> 
> If so, then we should add in a test for this query.  That way Brian
> can't check in anything that breaks this query.  :-)

Sounds like a good idea!

Regards
Steve



-----Original Message-----
From: gearon at gmail.com [mailto:gearon at gmail.com] On Behalf Of Paul
Gearon
Sent: 24 August 2006 19:00
To: Stephen Bayliss
Cc: Alexandre Passant; mulgara-general at mulgara.org; Martin Dow
Subject: Re: RE: [Mulgara-general] Query from restricted graphs

Hi Stephen,

On 8/24/06, Stephen Bayliss <stephen.bayliss at rightscom.com> wrote:
<snip/>
> 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']

I didn't notice this earlier.  Yes, the subject here should be the URL
of the model, and not the source document.  Alternatively, it could be
left as-is, and a new statement inserted:

[<rmi://192.168.0.1/server1#sampledata>, <namespace:cameFrom>,
<http://apassant.net/blog/sioc.php?type=post&id=104>]

Of course, the queries for talking to this would need to be changed.

<snip/>
> 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?

I think so, yes, but it shouldn't be a big deal.

> 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...
<snip/>
> 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>;

That's because the "localhost" got converted to what the system
believes is the "canonical name" for the server.  To see what the real
URL is, have a look at the contents of <rmi://localhost/server1#>.

This problem, along with some others, was addressed by Brian in
September.  However, the work was paid for by NGC, and they expressed
concern about us using it in the public domain.  NGC has since said
that it's OK, but to avoid any future problems Brian has promised to
re-implement it for Mulgara.  I know that he's swamped at the moment,
but he has told me that we can expect to see it in the near future.

> 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.

I believe that this was a part of Brian's fix.  So you can expect to
see a new incarnation of it soon.

> 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).

As I said, look in the system model <rmi://localhost/server1#> for the
type statements on each of these models, and use the URLs that you
find there.

> 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

Is this the query:
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>;

???

If so, then we should add in a test for this query.  That way Brian
can't check in anything that breaks this query.  :-)

Paul