[Mulgara-general] Two Database instances in the same process?

[Karsten Huneycutt]

Hello --

On Sep 27, 2009, at 4:56 PM, Paul Gearon wrote:

> Hi Karsten,
>
> On Sun, Sep 27, 2009 at 4:06 PM, Karsten Huneycutt <kph at skuld.us>  
> wrote:
>> Hello --
>>
>> First:  Does Mulgara 2.1.3 allow one to have two distinct Database
>> instances (and therefore two distinct XA1.1 StringPools, etc) in the
>> same process?
>
> I wish.  :-(
>
> Unfortunately, no. It's mostly there, but there are a few static
> variables that remain. I always wanted to fix this, but I've never
> tried to track it all down, because until now no one ever asked for
> it.

If I have more time, I may try to track this down -- having two  
processes for this is really sub-optimal for my needs.


>> A bit of background as to why I'm trying to do this:  I need to have
>> something that applies rules to a set of graphs (that the consuming
>> application accesses via a view) in the background that doesn't stop
>> modification of the original graphs while the rules are being
>> applied.  Each modification of the original graphs triggers a
>> background reasoning run, so any entailments that are invalidated by
>> the modifications will be corrected on the next pass of the reasoner;
>> for me, this temporary inaccuracy is an acceptable trade-off for the
>> responsiveness of modification that I require.
>
> You know you can always just have the results of rules sent to a
> separate graph. That would leave the first graph alone. Then when you
> want to look at the final results you select from a union of the
> original and the results graphs.

Yeah -- I was simplifying a bit.  The view used by the application  
actually includes an entailments graph, and the reasoner reasons  
across a second view without the entailments graph, and reasons into a  
staging entailments graph (so that the previous results are available  
while reasoning's going on).  Then, as a final step, the entailments  
graph used by the view is cleared and the staging entailments graph is  
copied into the original entailments graph, in one transaction.

I did it that way (staging entailments graph) because I wasn't sure if  
any invalid inferences would be removed from the entailments graph  
during the reasoning process -- eg, if the source graph contains:

A subclassOf B
A subclassOf C
B subclassOf D
C subclassOf E

the reasoner would then assert in the entailments graph:

A subclassOf D
A subclassOf E

If the original assertion A subclassOf C is removed from the source  
graph, would the reasoner remove A subclassOf E from the entailments  
graph without the entailments graph being cleared first?

On another note, I'm seeing some weird behavior.  I'm using rdfs- 
krule.rdf (with krule.owl), and the reasoner is asserting things like

"literal value here"^^<xsd:string> rdf:type rdfs:Literal
"literal value here"^^<xsd:string> rdf:type rdfs:Resource

or

"another literal"^^<xsd:string> rdf:type xsd:string
"another literal"^^<xsd:string> rdf:type rdfs:Resource

That's clearly not valid RDF, and is causing problems trying to get  
the data exported.  Is that expected, or is there something in the  
source graphs that could be causing this?  The same thing happens with  
rdfs.dl, too.

KH

-- 
Karsten Huneycutt
kph at skuld.us