[topicmapmail] AsTMa! as TMCL

[Robert Barta]

On Sat, Dec 14, 2002 at 06:28:25PM +0000, Kal Ahmed wrote:
> > > 2) There are no provisions for quantitative constraints (e.g. an
> > > association of type 'has-natural-children' must contain no more than two
> > > 'parent' role-players)
> >
> > forall $a [ (has-natural-children)
> >             parent : $p ]
> >    => forall $a [ (has-natural-children)
> >                   parent : $q ]
> >       => not exists $a [ (has-natural-children)
> >                          parent : $r ] is-reified-by at-most-two-parents
...
> It would still be a bit of a pain to have to do that for "every football 
> (soccer) team has 11 players and 2 subs" ... or "every football (American 
> football) team has 45 players (or whatever the number is)"

The above assumes that the players are all in _one_ association. If
you are happy to have this in separated assocs, like

(is-player-in)
team: flying-kangaroos
player: jon-downunder

(is-player-in)
team: flying-kangaroos
player: real-aussie

....

then you simply use a "quantified quantifier" (I like that one):

exists{11} [ (is-player-in)
             team   : flying-kangaroos
             player : * ]
and
exists{2}  [ (is-sub-in)
             team   : flying-kangaroos
             player : * ]

> > I see associations rather 'typed', i.e. not with too much varying roles as
> > I got the feeling that a map looses a lot of its strength using assocs
> > which 'float' in their structure. Maybe too much of a programmer's view.
> >
> 
> I think it does depend upon the viewpoint of the application developer - some 
> applications would benefit from the freedom to be able to redefine 
> association structures and create new association structures on the fly (e.g. 
> mind-mapping applications), whereas most applications requiring interchange 
> would find such freedom a problem.

Can you think of an example?

> > Of course it can. As soon as AsTMa! has a finite grammar (and it has), it
> > can be mapped according to its syntax. Similar to Holger's (in)famous
> > chapter in the XML book on KM engineering about software projects, you
> > simply create associations along the parse tree. The above would start as
> >
> 
> I would balk slightly at the thought of simply representing the parse tree. 
> I'm fairly sure that there must be more elegant ways of representing the 
> constraint structures in topic map form too. But I can see what you are 
> saying and I can see that that must imply that there would be *some* way of 
> representing  the constraint language.

I simply failed to map constraints (and also queries and updates) to intrinsic
topic map semantics except on the level of syntactic constructs.

Even if that could be established, still a TM application has to "recognize" it
has to do "the right thing".

\rho