[sc34wg3] Comments on Tau model

[Jan Algermissen]

Robert Barta wrote:
> On Mon, Jul 26, 2004 at 08:03:49PM +0200, Jan Algermissen wrote:
> 
>>Lars,
>>
>>that is exactly the point I am trying to make. Without some requirements,
>>the choice of the underlying model is arbitrary.
> 
> 
> Uhm, well, no :-)
> 
> Of course, we could approach all this with a "requirements-driven"
> approach.  We could have a list (takes looooong discussions over many
> years and still..), then someone would sit down and write and then
> someone else would evaluate whether....
> 
> This may work when creating shoes, mobiles, patios, application
> software (ha!) and other commodities in a market. I doubt this is a
> viable way to create (a) an infrastructure or (b) a new information
> model like TMs want to become.

Ah! That's what you understand Topic Maps (as a paradigm, not the docs) 
'are'. Unfortunately, I have no idea what you mean by

- infrastructure

- information model

Can you explain or define the terms?

The reason I ask is because I believe that within the TM community, 
there are several very different understandings what TMs 'are' and thus 
different people approach the question of 'what is the underlying nature 
of TMs?' very differently. Unfortunately, ISO13250 does not really 
provide a compelling answer.

Jan


> 
> Much more realistic seems to me that we have a rough concensus, build
> a prototype/sketch, see how far we come and use several iterations of
> this.
> 
> 
>>Robert's proposed information structure is extremely unconstraining,
>>which provides great freedom for the data modeler but does not
>>provide the implementor with much structure that can be relied on
>>for efficiency.
> 
> 
> You would surprised to hear that I choose a structure quite similar to
> \tau assertions for my new Perl software. Not only is it amazing
> memory effective, first experiments also show it is fast as hell as I
> use only lists and lists of lists (Perl is rather efficient
> thereby). And I have not even started to memoize critical functions.
> 
> 
>>Even the whole idea of merging would have to be handled by the query
>>language (by the operators in general).
> 
> 
> Mathematically, merging (or more precise: the various flavors thereof)
> is done with TMQL expressions. But, of course, software would solve this
> by hard-coding the functionality. Example:
> 
>   my $tm = new TM (tau => "file:map1.atm + file:map2.xtm");
> 
> This loads both maps and puts them together. No merging takes place
> except when topics obviously have the same subject identification.
> 
>   my $tm = new TM (tau => "(file:map1.atm + file:map2.xtm) * tm:/queries/tnc");
> 
> Again, both maps are loaded, but this time the TNC (topic naming
> constraint) will be applied. Of course the software realizes "oh oh, I
> know what this operator does" and it will say "no, I do not do this
> manually with TMQL, I optimize this with a function I have in a
> package". And off we go.
> 
> The fun thing is that this also works for "virtual maps", i.e. maps which
> are actually only a wrapper around some other resource (I usually use DNS
> as example):
> 
>   my $tm = new TM (tau => "(file:dns.ont + dns:localhost) * tm:/queries/tnc");
> 
> Now the "+" merging operator is faced with the fact that it cannot
> completely load the map addressed by 'dns:localhost'. If the "+"
> operator tries to "sync in" this map, the driver which handles the
> communication between the TM software and the DNS resolver library
> will refuse to load "the whole DNS data".
> 
> Still, you can write in your application
> 
>    print $tm->path ('firewall -> host \ has-ip-address / ip-address');
> 
> as if this were a single map, and you are oblivious on the effects of
> the TNC. The "*" operator will take care that the TNC constraints are
> satisfied "upwards" to the application while the maps "downwards" are
> still completely separated.
> 
> 
>>Of course, a store can implement the owl:same semantics, but then it
>>uses more information than has been provided by the data model
>>itself. It would be like an RDBMS that comes with a set of
>>predefined tables for some specialized task.
> 
> 
> Oracle does just that. And nothing can be said against predefined
> functions in products.
> 
> \rho
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>