[topicmapmail] AsTMa! as TMCL

[Robert Barta]

On Mon, Dec 09, 2002 at 10:18:50AM +0000, Kal Ahmed wrote:
> Firstly, let me just say that there is a lot of interest in this proposal.
> 
> Some initial comments:
> 
> 1) There is nothing in the document about the treatment of conflicting 
> constraints. Especially where a topic may have multiple types, it could be 
> quite easy to end up with such conflicts. There should be some form of 
> resolution (perhaps precendence rules based on file order ?)

Hmm, right. While it is unlikely that it occurs in one constraint, it may
well happen that - when two constraints are combined - they are inconsistent.
So when m is valid against a constraint c1

   c1 |= m

and against c2

   c2 |= m

then maybe not against both of them (* means 'AND'):

   (c1 * c2) |/= m

AsTMa! already has a 'suggests' modifier to relax constraints, but nothing to
make them relaxed aposteriori.

I am not sure whether and how a language should deal with it:

  - it may be an error in the map. fullstop. fix the map or remain invalid.

  - Or, it may be an error in the map. but who cares as most of it is ok.

  - Or, it may be an known defect of how the constraints interplay, let's fix that later, when MS has bought us up.

  - Or, it is a defect in one constraint, that it does too much.

  - ....

I do not think that the constraint language itself should handle this, as it depends
on the intention. I rather tend to believe that this has to be handled at the 'management
level' to moderate/mediate. Maybe something like

   ( c1 - "...relax offending constraint..." ) * c2 |= m

which takes c1 but removes the problem and only then proceeds. The '-' operator
would be a 'negative' merge using an TMupdate language.

Then the engineer can control precisely _what_ he/she wants.

> 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

Since same variables _have_ to be bound to the same things and different variables 
_have_ to be bound to different values (weird, I admit, but handy), this should work.
AsTMa! has a lot of secondary syntax to make life easier:

   http://astma.it.bond.edu.au/astma!-spec.dbk?section=10

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.

> 3) As a smaller niggle, why do regular expressions which contain a / character 
> require a different syntax to other regex's when Perl regex's allow / to be 
> escaped ?

Maybe the tutorial insinuates that (will fix it, in case), but this is plain
vanilla Perl regexp. (Or whatever, the language structure does not depend on it).

> As an aside, it is interesting that most constraint language proposals involve 
> the creation of a new syntax for their expression. Having started down the 
> road of developing a constraint language using XTM syntax (based on the 
> original work done by Steve Newcomb and Michel Biezunski on association 
> templates), I am aware of the verbosity of such a solution, but it would be 
> nice to see if/how a constraint language such as AsTMa! could be mapped into 
> topic map constructs (even if the original AsTMa! syntax is retained).

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

<topic id="at-most-two-parents">
   <instanceOf>
      <topicRef href="http://www.topicmaps.org/....#constraint"/>
   </instanceOf>
</topic>

<assocation>
   <instanceOf>
      <topicRef href="http://....#composes-constraint"/>
   </instanceOf>
   <member>
      <roleSpec>
          .....whole-constraint
      <topicRef .....#at-most-two-parents/>
   </member>
   <member>
      <roleSpec>
               list-of-clause      <!-- here goes the top-level non-terminal -->
   </member>
</association>

And then you automatically drill down the syntax tree. (Someone simply has to define
the PSIs for all the non-terminals, not a big deal).


I guess at this point everyone agrees that direct XTM is no fun to write.

\rho

> On Sunday 08 December 2002 09:07, Robert Barta wrote:
> > Hi,
> >
> > In case you are interested where we (Bond) currently stand with our ideas
> > about constraining TMs (aka TMCL), see our new tutorial and the last
> > version of the language specification:
> >
> >    http://astma.it.bond.edu.au/constraining.xsp
> >
> > Constructive comments welcome!
> >
> > \rho
> > _______________________________________________
> > topicmapmail mailing list
> > topicmapmail@infoloom.com
> > http://www.infoloom.com/mailman/listinfo/topicmapmail
> 
> -- 
> Kal Ahmed, techquila.com
> XML and Topic Map Consultancy
> 
> e: kal@techquila.com
> p: +44 7968 529531
> w: www.techquila.com
> 
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail
>