[Mulgara-general] TQL via webui

Alex Hall alexhall at revelytix.com
Tue Aug 25 19:32:44 UTC 2009


Gregg Reynolds wrote:
> On Mon, Aug 24, 2009 at 4:22 PM, Alex Hall<alexhall at revelytix.com> wrote:
> 
> Thanks, Alex.  Couple of questions below.
> 
>> Gregg Reynolds wrote:
> 
>>> Now I want to drop the graph.  In iTQL, I get an error:  "Unable to
>>> remove <uri>: Cached content can't be removed".  So question one is,
>>> whaaa?
>> This error message indicates that a request was made to drop a graph
>> whose URI uses the HTTP scheme, and which is not recognized as an
>> internal graph.  In this case, Mulgara treats the graph URI as the URL
>> of an external RDF document; you can use Mulgara to query the contents
>> of RDF documents accessible on a filesystem or network but you can't use
>> Mulgara to delete these external documents.
> 
> Hmm.  This was a graph to which I loaded data from a file on the local
> fs.  Are you saying that Mulgara interprets a "drop" command as a
> request to delete the file?  I would expect it to just drop it from
> its memory.

Mulgara interprets a "drop" command as a request to drop some graph from
internal storage.  If it has no record of a graph with the given URI,
then it can't delete the graph.  Admittedly, it should probably give a
nicer error message than "Cached content can't be removed" if it can't
find the graph to remove.  At any rate, the sequence of TQL operations
to create a graph, load content from a local file, and drop the graph is:

tql> create <my:graph:uri>;
tql> load <file:/var/tmp/foo.rdf> into <my:graph:uri>;
tql> drop <my:graph:uri>;

This sequence should work for any valid URI that you choose as the graph
identifier.

>>> "HTTP ERROR: 400
>>> Error executing command. Reason: Distributed models cannot be removed
>>> RequestURI=/webui/ExecuteQuery"
>>>
>>> So question two is "whaaa?"
>> Similarly, this error message indicates that a request was made to drop
>> a graph whose URI uses the RMI scheme, and which is not recognized as an
>> internal graph.  In this case, Muglara assumes that the graph is stored
>> on a remote Mulgara server and will access the contents of the remote
>> graph for a query operation but will not let you delete the remote graph.
> 
> Ok, from this and other messages I infer that the URI of a graph is
> more than just an identifier of a graph; in this case, it doesn't just
> mean "this is a graph", but "this is a graph living somewhere else".
> If the URI uses rmi:, iTQL takes it as a request to use RMI.  In other
> words, Mulgara assigns operational semantics to URIs; is that correct?

The answer is somewhere in between.  The usage of graph URI's has
evolved over the years from purely operational semantics to where it
stands today, and I'll attempt to explain the current status without
going into all the gory details.

Mulgara distinguishes between internal and external graphs.  Internal
graphs are controlled by the server, and their life cycles are
controlled using the "create" and "drop" commands.  Graph URIs for
internal graphs are pure identifiers; they are completely opaque to the
system and can be any format so long as they are valid per the
java.net.URI class which implements RFC 2396.  The system graph which
you've seen referenced before maintains a list of all internal graphs
for the server.

When you execute a query, or any other operation which accepts a graph
URI, Mulgara assumes it's the identifier for an internal graph and looks
for it in the system graph.  If it finds the identifier in the system
graph then it accesses the graph contents without any further processing
of the graph URI.  If it does not find the identifier in the system
graph, then it assumes it's an external graph.  External graphs are
exactly what they sound like -- external to the system and accessible
via some protocol.  This is where the operational semantics come into
play.  If you're executing a query, then Mulgara treats the graph URI as
a URL and examines it for hints about where and how to access the
content.  The content is never stored locally; it is cached for the
duration of the query operation and then discarded.

In other words, I am free to create a graph called
<http://example.com/MyGraph> using the create command, and I can load
content into it and execute queries against it using that URI.  If, on
the other hand, I query a graph with the URI
<http://example.com/FooGraph> and this graph doesn't match the
identifier of a locally stored graph then Mulgara will make an HTTP
request to example.com to try and retrieve the graph contents.  This can
often be a useful feature; you can use Mulgara to process the contents
of RDF documents on a network or filesystem without having to load them
into memory on the server.

>> I'm not sure if this is what you're attempting to do, but you can't
> 
> Just trying to get the hang of it.  Mulgara seems like a pretty sweet
> package, VASTLY easier to get started with than e.g. Jena with a
> storage back end, but I confess discouragement is creeping in.  Poor
> documentation is a big big problem.

Understood.  We are well aware that the documentation is lacking, but
everybody is stretched so thin that fixing the documentation takes a
back seat to bug fixes and new features.  We try and keep the wiki
updated for any new development work that we do, but the legacy
documentation for core system functionality is so far out of date as to
be next to worthless.

Regards,
Alex



More information about the Mulgara-general mailing list