[Mulgara-general] Query from restricted graphs

Paul Gearon gearon at ieee.org
Thu Aug 24 17:59:57 UTC 2006


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



More information about the Mulgara-general mailing list