Re: TM is TMQL output

On Thu, Jun 26, 2003 at 08:04:14PM +0200, Thomas Schwotzer wrote:
> TMQL requirements 1.0.0 paragraph 3.3.8 states:
> 
> > TMQL may define operations for constructing topic maps from the 
> results of TMQL queries.
> 
> What will be part of the newly created topic map?
> 
> 1. Only topics that match the TMQL query?
> 
> 2. Topics that match the TMQL query AND topics
> which are (directly?) associated with matching topics?

Thomas,

Good question. Probably (hopefully),

3. You get what you ask for.

In some cases, it's the topic(s) you are interested, in others the
assocs. Sometimes it's a mixture of both. So the standard cannot
constrain this.

tolog tackles this with its select clause, where you project out of
the set of variables and their values only those you are interested
in.

AsTMa? uses as default the maplet concept: This means all associations
you have asked for and - whether you want it or not - get all the
topics which are involved there. [ AsTMa* is more biased towards
assocs. A topic is actually a specialized assoc. ] If you do not like
the default, then yo can use a 'return' clause to create whatever you
want (XML, XTM, raw maps, ..).

> Second version would lead to a kind of fragmentation algorithm.
> I wonder if fragmentation should be task of a query language.
> Should it?

With 'fragmentation' you mean that a query produces a 'submap' (i.e.
a subset of topics/assocs of the original map)? If so, then
defininitely so. But I cannot see a way around this.

OTOH if we allow arbitrary content to be generated in one go (and I
think it is all about reducing the interaction with the application to
get the performance), then the output can be _completely_ decoupled
from the map we are querying.

Actually, AsTMa? does not have the concept of an 'input map' because
there you can 'query' (i.e. process) two or more maps at the same time.

> Maybe an answer is not given by TMQL standard but by a
> TMQL implementation?

I agree here with Lars that for a 'standard' we need more experiences
first. I would hate to produce something ugly (and successful) as
SQL....;-}}

So more proposals would be highly welcome.

\rho