[tmcl-wg] comments regarding TCML requirements draft

[Robert Barta]

On Thu, Feb 27, 2003 at 04:39:03PM +0100, Bernard Vatant wrote:
> I'm concerned with overlapping, matching, conflict between constraints
> like the two following ones:
> 
> C1. (on topic type)
> "Topic of type X may (must) play role type R in association of type A"
> 
> And
> 
> C2. (on association type)
> "Association of type A may (must) use topic of type X for role type R"
> 
> Those are clearly two ways to achieve quite similar objectives, from two
> viewpoints (although not exactly equivalent). Which is the best way?

Bernard,

As you say, they are not equivalent, and - as you say further down - it
may depend what to use.

C1 and C2 will look quite different in any future TMCL. (Using AsTMa!):

forall [ $t (X) ] => exists [ (A)
                              R : $t ] is-reified-by C1

forall [ (A) ] => exists [ (A)
                           R : $t ]
                  AND
                  exists [ $t (X) ] is-reified-by C2

and they also have different models (in a logic-model oriented sense).
C1, for instance, is true for a map which does not contain any topic of
type X, but some associations of type A. This map does NOT conform to C2.

> Should we provide ways to do both?

Yes, in the same way as it is perfectly OK for us to use

 z (x + y)

and

 (y + x) z

as terms over the natural numbers. Even though, as in this case, it
can be proven they are equivalent. The semantics of the algebra (or
the language) allows that proof.

> 1. If TMCL supports both types of constraints, it would be nice to make
> it clear what are the use cases and scenarios for each one.

Both are perfectly valid.

> 2. If one schema uses C1 and another one (or the same one) uses C2,
> checking consistency at editing or merging time seems to be tricky. 

Well, the machine will have to check 2 constraints instead of one.
Clever software may implement incremental checking.

> I am more and more inclined towards using rather C1 than C2, although
> until a few months ago I was thinking the other way round (including in
> my Baltimore paper). Why?

I think regardless of your observations (which are interesting, BTW),
at this stage we cannot take this heuristics as basis for the
language. In a programming language you also can write

 while (1)
    exit;

which does not make any sense, but has a precise semantics. Let future
users decide how to (ab)use the language.

> Of course, we want TMCL to be more expressive than frame-based
> ontologies. But a requirement IMO should be the interoperability with
> that kind of legacy, the same way topic maps being more expressive than
> Thesaurus must not prevent the ability for TM to integrate easily
> Thesaurus structures. 

What 'legacy' are we exactly talking about? Is this something which
has to be put into a language or is it what we can burden to tools?
We need a lot to help the vendors distinguish themselves. It is VERY
contraproductive for the market to have fat standards with little
leeway. This only helps the big companies.

> IOW, the global strategy against existing tools should be:
> 
> "We can do all what you do, in a very similar way, but we can do more" 

Yes, this is the Microsoft way. ;-)

\rho