[Mulgara-dev] Krule updates

[Alex Hall]

Paul Gearon wrote:
[snip]
>> apply <ruleGraph> to <graphA> or <graphB> or <graphC> <graphD>
>>
>> Now that's not exactly self-explanatory.
> 
> That's my problem. The fact that the final graph just "hangs" off the
> back there has always bothered me. OTOH, it worked when there was only
> one other graph.

Yes, that's exactly what I was thinking but couldn't quite find the
words to express.  The destination graph just hangs off the end there.

>>  I suppose there are things you
>> could do to clean it up.  One thing that comes to mind is introducing a
>> keyword -- "into" or "destination" seem like logical candidates -- to
>> separate the graph expression from the destination graph.
> 
> I was originally going to do this, but it felt too much like syntactic
> sugar at the time, so I just added the graph on the end. It would
> *still* be syntactic sugar, but now it would add significantly to the
> readability.

I think this is the approach I will take, then.  If necessary, the new
keyword might be made optional if we decide it's important for the
grammar to be backwards-compatible with existing commands.

[snip]
> Incidentally, that raises the question of the default place to put
> data if you have multiple sources. When there was only one source,
> then this was the default place to put the entailed data, but with
> multiple sources then the default would probably have to be the
> default graph. Incidentally, we HAVE a default graph now (it'll be in
> the next release). By default it's called <sys:default> but it's
> configurable at startup time.

I was thinking about this as well.  Not knowing about the default graph,
I thought that you would need to force the client to explicitly state
the destination if using a complex base expression.  But a default graph
(as long as it isn't <sys:null>) works as well.

>>>> 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>?
>> Because the file will reside on the user's workstation, and will be
>> coming in to our web application as an InputStream as part of a file
>> upload form.  It won't be publicly accessible over HTTP from the server.
> 
> Ah, OK. This looks exactly like what I already have for loading files
> over HTTP, so this will be easy code to write.
> 
> It also looks like the pre-binding I mentioned to you in IM yesterday,
> and which I'm talking about in a blog post at the moment. Look for it
> later today (or tomorrow).

Will do.

>>>>  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.
>> Yeah, I suppose you're right.  I'll just have to come up with some way
>> of making the contents of that InputStream accessible to the Mulgara
>> server as a graph.
> 
> The pre-binding thing I'm talking about will be doing almost exactly
> what you want. The missing piece it loading it into a temporary graph.
> There is an existing mechanism for this already, though I don't know
> the details (this is the system employed when you choose a graph URI
> of http:// that you don't know about, and the system gets the document
> with the HTTP resolver, and interprets it into a temporary graph using
> a content handler).

OK, I'll take a look at that when it becomes available.  For the time
being, it isn't too much of a burden to manually manage a temporary
graph to hold the rule definitions.

Regards,
Alex