[sc34wg3] Possible TMRM issue

Lars Marius Garshol larsga at ontopia.net
Mon Mar 20 08:30:16 EST 2006


* Jan Algermissen
>
> I think you need to sort out first, if the RM is meant to be  
> implementable in the abstract sense or if only applications of it  
> (e.g. TMDM) have to be implementable.

That's definitely true, but my attempts to clarify this over the past  
four-five years have so far failed to yield any definite answers, and  
so I've given up on that approach, and now navigate by hearsay. What  
I do see is that Steve N. sometimes seems to imply that there will be  
implementations, that Robert Barta and Lars Heuer are working on  
implementations, and that Patrick just wrote in a that seemed to  
imply that there would be implementations.

> I think Steve and Patrick think the latter.

I'm not in a position to contradict you.

> If it is the latter case then implementations can use the  
> additional semantics to build the neccessary indexes.

Yes, they can. TMDM implementations do not have this issue.

> FWIW, I did implement a former version of the RM. I am not sure how  
> much the model changed since then but I had the same issue back  
> then. I solved it by adding the constraint that properties have to  
> have fixed value types and that value type dependent plugins needed  
> to be supplied. This solved the underlying problem that you can  
> only implement efficient storage and indexes when you know the data  
> type.

The problem is that the value of one proxy depends on the values of  
other proxies, which again depend on... So even if you can bottom out  
for the literals that doesn't mean you can do this efficiently for  
the graph as a whole.

> And you need the indexes to do merging in O(log n) time. It is I  
> guess the most complex thing I ever did, but it worked and scaled.

That's only the start, though...

> The tricky thing is that property values can contain proxies  
> (assuming it still works that way), and that merges of proxies  
> cause changes to property values that in turn can (and often will)  
> lead to further pending merges.

Yes. This is the part that concerns me.

--
Lars Marius Garshol, Ontopian               http://www.ontopia.net
+47 98 21 55 50                             http://www.garshol.priv.no




More information about the sc34wg3 mailing list