[topicmapmail] AsTMa! as TMCL

[Kal Ahmed]

On Saturday 14 December 2002 02:30, Robert Barta wrote:
> 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 conflictin=
g
> > constraints. Especially where a topic may have multiple types, it cou=
ld
> > be quite easy to end up with such conflicts. There should be some for=
m of
> > resolution (perhaps precendence rules based on file order ?)
>
> Hmm, right. While it is unlikely that it occurs in one constraint, it m=
ay
> well happen that - when two constraints are combined - they are
> inconsistent. So when m is valid against a constraint c1
>
>    c1 |=3D m
>
> and against c2
>
>    c2 |=3D m
>
> then maybe not against both of them (* means 'AND'):
>
>    (c1 * c2) |/=3D m
>
> AsTMa! already has a 'suggests' modifier to relax constraints, but noth=
ing
> 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 inva=
lid.
>
>   - Or, it may be an error in the map. but who cares as most of it is o=
k.
>
>   - 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 |=3D 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.
>

Perhaps that is the right approach. After all, most XML editors allow a u=
ser=20
to continue editing a file when it does not conform to its declared schem=
a -=20
and most will let you save an invalid file. So in the editing environment=
, =20
it could be acceptable/desirable to make any constraint violation simply =
a=20
notifiable event. However, when merging data from another source, a topic=
 map=20
user may wish to reject any data that does not conform to the agreed set =
of=20
constraints. Another feature that makes AsTMa! interesting is that one ca=
n=20
constrain the set of types, making constraint validation capable of=20
guarunteeing that received data conforms to some agreed ontology - thats =
a=20
really useful thing to be able to do.

> > 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 ]
>    =3D> forall $a [ (has-natural-children)
>                   parent : $q ]
>       =3D> not exists $a [ (has-natural-children)
>                          parent : $r ] is-reified-by at-most-two-parent=
s
>
> Since same variables _have_ to be bound to the same things and differen=
t
> 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=3D10
>

It would still be a bit of a pain to have to do that for "every football=20
(soccer) team has 11 players and 2 subs" ... or "every football (American=
=20
football) team has 45 players (or whatever the number is)"

> 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=
=2E
>

I think it does depend upon the viewpoint of the application developer - =
some=20
applications would benefit from the freedom to be able to redefine=20
association structures and create new association structures on the fly (=
e.g.=20
mind-mapping applications), whereas most applications requiring interchan=
ge=20
would find such freedom a problem.

> > 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 no=
t
> depend on it).
>
> > As an aside, it is interesting that most constraint language proposal=
s
> > involve the creation of a new syntax for their expression. Having sta=
rted
> > down the road of developing a constraint language using XTM syntax (b=
ased
> > on the original work done by Steve Newcomb and Michel Biezunski on
> > association templates), I am aware of the verbosity of such a solutio=
n,
> > but it would be nice to see if/how a constraint language such as AsTM=
a!
> > 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
>

I would balk slightly at the thought of simply representing the parse tre=
e.=20
I'm fairly sure that there must be more elegant ways of representing the=20
constraint structures in topic map form too. But I can see what you are=20
saying and I can see that that must imply that there would be *some* way =
of=20
representing  the constraint language.

Cheers,

Kal
--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy

e: kal@techquila.com
p: +44 7968 529531
w: www.techquila.com