[sc34wg3] Possible TMRM issue

[thomas]

very interesting. reminds me off like the difference between OWL DL and OWL 
Full?

perhaps there is a way to draw a line within which the 
chasing-it's-own-tail proxy-of-proxy can be confined? making the step from 
decidability to undecidability explicit?

(there surely is, but:)


how if that line could be made explicit at runtime, in a rather fluid way? 
wouldn't that give something like a scope on a problemspace and make an 
otherwise undecidable question decidable under a given scope?


that would be great since it is anyway the way in which "truth" is 
generated - there always is a condition, otherwise you fail to generate 
answers that are more meaningful than "42". at least to me and now it feels 
like a quite natural way ;-)

hope this is clear in any way
thomas



--On Montag, 20. März 2006 14:30 Uhr +0100 Lars Marius Garshol 
<larsga at ontopia.net> wrote:

>
> * 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
>
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3 at isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3



.
mailto:thomas at stray.net
http://stray.net

..
early optimization is the root of many evil
donald e. knuth

...
Ab 1948 lehrte Turing an der Universität in Manchester. 1952 schrieb er ein
Schachprogramm. Ohne über einen Computer mit genügend Leistung zu verfügen,
um es auszuführen, übernahm Turing dessen Funktion und berechnete jeden Zug
selbst, was ihn um die 90 Minuten pro Zug kostete. Das einzige
mitgeschriebene Spiel verlor er gegen einen Kollegen.
http://de.wikipedia.org/wiki/Turing