[sc34wg3] Comments on Tau model

[Robert Barta]

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.

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