Re: implementing triple stores

On 10 May 2009, at 15:08, Sandro Hawke wrote:

>> On 9 May 2009, at 13:40, Sandro Hawke wrote:
>> [snip]
>>> Right.  The interesting/challening part, I believe, is that Gary  
>>> wants
>>> to translate frames to Java objects.  Doing so will require some
>>> cleverness, since there are significant semantics/functionality
>>> differences, but hopefully will give significant performance gains.
>>> Ternary predicates are typically not super fast at matching (a,b,?).
>>
>> Really?
>
> I don't understand.  You seem to be disagreeing with my claim,

I was.

> but then,
> below, you seem to be support it.

My understanding of what I subsequently wrote is that I was supporting  
my disagreement.

>  I'm trying to claim that a naive
> system which just uses an ordinary rdf/3 predicate is not likely to be
> able to list all the object for a given subject+predicate very quickly
> (compared to a less-naive implementation.)

But not due to a fundamental property of the system, which you seemed  
to be implying. Using "isIndex" *is* using the built in predicate  
indexing system.

>>> (For example, SWI-Prolog uses a specially indexed structure for RDF
>>> triples/quads, because normal predicate indexing is too slow.)
>>
>> I wouldn't think that's the issue. Predicate indexing is typically  
>> one
>> of the more optimized part of a Prolog engine (for obvious  
>> reasons). A
>> uniform ternary predicate *defeats* predicate indexing because  
>> there's
>> only one predicate. By default, IIRC and it hasn't changed, most
>> Prolog engines do predicate plus first argument indexing, though you
>> can change that, e.g.,:
>> 	http://www.lix.polytechnique.fr/~catuscia/teaching/prolog/Manual/sec-3 
>> .
>> 11.html#sec
>> :3.11.1
>> 	http://www.lix.polytechnique.fr/~catuscia/teaching/prolog/Manual/sec-3 
>> .
>> 12.html#index/
>
> I can't find a web page describing it, but from what I recall, the SWI
> Prolog RDF store (which is really a quad store) has about 8 hash
> indexes, convering different combinations of subject, predicate,  
> object,
> and graph.

Sure. But you might want to have more hashing with a p(s, o)  
representation too (e.g., if you have lots of queries based on  
objects). I don't see that the reified representation makes a  
fundamental difference.

[snip]
> I tend to think having a hash table per object/frame gives good enough
> performance, but it is cool to be able to do various other queries
> quickly as well.

My point was that p(s,o) vs. t(s,p,o) in a typical Prolog system is  
pretty much adding an isIndex call for the former. Thus, "naive  
performance"  isn't a reason (in those systems) for preferring one to  
the other. Performance of various queries *is* a reason for preferring  
another representation altogether.

Cheers,
Bijan.

Received on Sunday, 10 May 2009 16:04:01 UTC