[Mulgara-dev] Krule updates

[Paul Gearon]

Hi Alex,

As suggested, I've moved this to mulgara-dev....

On Wed, May 20, 2009 at 2:54 PM, Alex Hall <alexhall at revelytix.com> wrote:
> Hi Paul,
>
> This was the other thing that I wanted to talk to you about before we
> got side-tracked on memory mapping and query planning.  A few things:
>
> 1. We talked briefly about extending Krule with the ability to apply
> rules to complex graph expressions, and you indicated that this could
> take a lot of work.  In looking through the code, however, I see that
> Krule already applies rules to complex graph expressions -- if the
> derived statements are to be inserted into a different graph from the
> base graph, then the rules are actually applied to the union of the two
> graphs.  Extending this to allow for general graph expressions for the
> base facts will involve (1) expose this capability to clients by
> modifying the RuleLoader, Session, and Connection interfaces, and (2)
> extending the TQL grammar to specify complex base graphs.  The first
> part is all I'm really looking for, and would be straightforward.  The
> second part can be as simple or complex as we want to make it --
> obviously handling complex set expressions is going to be more involved
> than just taking a list of URI's and combining them as a union.  If this
> can happen in parallel with your SWRL parsing work, then I'm happy to
> bite off this task.


I had a few concerns about this. The first was the syntax. I suppose
it can be the same expression that TQL uses in a FROM clause. It'll
make the syntax even more obtuse than it is (I didn't like it in the
first place), but I guess it will work.

The second problem is that unions need to be optimized. I haven't
looked at it, but Andrae tells me that while it should be trivially
efficient, it isn't.

Finally, I was concerned about how multiple input graphs would
interact with the optimizations that are scheduled to go into Krule.
In the case of graph unions (OR) then it should be OK, but will
require extra code. It may not be optimally efficient for
intersections, but my brief consideration of it suggests that it
should be correct all the same.

However, overall I guess there's no *real* problem. Just some things
to consider.


> 2. Have you made any progress on the SWRL parsing?  Can you give me an
> estimated completion date?  We need to upgrade Mulgara versions in the
> very near future for unrelated reasons (we're still on 2.0.x and want to
> start using the XA1.1 statement store) and if possible I'd like to
> coordinate those upgrades.  That in turn means that I'd prefer the SWRL
> upgrades to be in a released version soon, because I *hate* deploying
> production code with Mulgara snapshots from SVN.


No, I haven't, sorry. I have to set up the new Topaz servers this week
(everyone knows about the Topaz project, right? :-)  It's an
object-layer over Mulgara, like an ORM), and I still have things to do
there. Also, I've been looking at Saxon in order to get XQuery
functionality for both SPARQL and SWRL, and I didn't want to move
ahead until I had it in there.


> 3. I'm going to be taking SWRL rules input in the form of RDF/XML files
> uploaded to a webserver.  The webserver may or may not be running in the
> same place as Mulgara, so I can't necessarily use a file:/ URI when
> applying the rules. At the moment, it seems the only possibility is to
> upload the rule file into a (temporary) graph on the Mulgara server and
> apply the rules from there.


Why not refer to the rules as <http://hostname/path/rules.rdf>?


> Another option might be to extend the
> ApplyRules command to accept an InputStream -- do you think that's an
> option worth exploring?


The API could be updated to do this, but you can't do it in a TQL command.

Since you're only looking at RDF/XML (and a content handler could
convert from SWRL/XML to SWRL/RDF), then I don't think you should be
looking at files (or input streams). You should be looking at graphs.


> 4. How do you pronounce Krule?  Is it "cruel" or "k-rule"? :-)

Cruel. I named it back when it was "KowariRules", so "Krule" seemed
droll. Now that the project is no longer "Kowari" the name doesn't
make as much sense. I thought of "Mule" but opted against it.  :-)

> BTW, feel free to move this conversation to mulgara-dev if you think
> it's appropriate.  Things have been pretty quiet on there lately...

Done.

Paul