[Mulgara-general] TQL via webui

Paul Gearon gearon at ieee.org
Wed Aug 26 12:06:58 UTC 2009


I'm on the road at the moment, but using the hotel's free WiFi to
catch up on podcasts for the drive, so I thought I'd check my mail
while I was at it.  :-)

On Tue, Aug 25, 2009 at 4:12 PM, Gregg Reynolds<dev at mobileink.com> wrote:
> Huge thanks for taking the time, Alex.
>
> On Tue, Aug 25, 2009 at 2:32 PM, Alex Hall<alexhall at revelytix.com> wrote:
>> Gregg Reynolds wrote:
>>> On Mon, Aug 24, 2009 at 4:22 PM, Alex Hall<alexhall at revelytix.com> wrote:
>>>
>>>
>>> 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
>
> Ok, since my setup involves cygwin and a machine I don't totally
> control, I'm going to guess that there is some kind of configuration
> weirdness involved.

Perhaps, though I doubt it in this case. What you really need is some
way to see the URIs of the internal graphs. Fortunately, that's easy.
:-)

In SPARQL, just query the # graph (this is a valid relative URI):

  SELECT * FROM <#> WHERE { $s $p $o }

In TQL, you can do the same thing:

  SELECT $s $p $o from <#> WHERE $s $p $o

(incidentally, the # is relative to the server URI, which is something
like rmi://localhost/server1#)

The URIs you are looking for will have an rdf:type of
http://mulgara.org/mulgara#Model

(this can be changed, but it sounds like you haven't set the system up
to use a different graph type)

>> 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>;
>>
>
> I'll try this at work tomorrow.  The graph I couldn't drop was created
> and loaded via the web interface.  Something odd happened, but then
> again I'd better try to duplicated it to make sure I'm not forgetting
> something.

As I said, query to see your existing graphs. You may have been trying
to drop the wrong URI.

>>> 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
>>
>> Mulgara distinguishes between internal and external graphs.  Internal
> ...
>
>> 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.
>
> Ok, seems reasonable, based on the interpretation of URIs in RDF; my
> question then is whether this is kosher from a standards perspective.
> Or maybe a better question is, is this the way Mulgara behaves
> regardless of access method (for lack of a better term)?  I'm thinking
> of the difference between TQL and SPARQL access.  Feel free to ignore
> this question, unless you think it would be good to have it in the
> archives; I need to reread to SPARQL specs to research it.

Access method doesn't matter for this. Both languages get compiled
into the same algebra, and the query engine runs this algebra. The
difference is that each language is capable of creating algebraic
constructs that don't exist in the other language (for instance,
SPARQL can FILTER data, and TQL can traverse transitive predicates).

>>> storage back end, but I confess discouragement is creeping in.  Poor
>>> documentation is a big big problem.

This is depressing to read because I know how true it is.  :-(

As Alex says below, a big reason is because we each have priorities
for implementation that don't extend into documentation. I'd love to
have the spare time to sit down for a couple of months an get it all
up to date, but it just can't happen. Every so often I try to take
stuff from docs.mulgara.org and move it to the wiki, with corrections
along the way, but this is time consuming which makes it hard to
justify to those I'm beholden to.

Maybe I should make a commitment to documenting anything that gets a
specific request (like this). It may make the wiki indexing a little
haphazard, but more will get done this way. Besides, wiki's are
supposed to be haphazard.  :-)

The reason I'm answering emails while on the road is because I want to
make up for the lack of docs in some way by being as responsive as I
can be. (unfortunately the kids are getting anxious, so I don't think
I'll get to respond to the other messages in my inbox).

>> 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
>
> No problem, been there, done that, not meant to be a whine, just an
> observation. Mulgara looks a lot like a project on the verge of
> breakout, if not for the documentation.  Kinda like RDF in general, I
> guess.  ;)

LOL. Mulgara was one of the very first RDF stores, back when it was
called TKS (Tucana Knowledge Store), so it's obviously been on the
verge for about 9 years now.  :-)

Mind you, we've included a lot of features recently (many of them were
easy to do, given the extensiveness of the infrastructure), so it
seems to be much more appealing to users all of a sudden.  I know
this, because I'm a user too, and *I* find it more appealing these
days.  :-)

Regards,
Paul



More information about the Mulgara-general mailing list