[topicmapmail] AsTMa! as TMCL

[Kal Ahmed]

On Saturday 14 December 2002 21:10, Robert Barta wrote:
> 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 t=
han
> > > > 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-parents
>
> ...
>
> > It would still be a bit of a pain to have to do that for "every footb=
all
> > (soccer) team has 11 players and 2 subs" ... or "every football (Amer=
ican
> > 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 : * ]
>

OK. I think that addresses a number of use cases that I had in mind.But I=
=20
would still prefer to see an extension of the "quantified quantifier" syn=
tax=20
to allow it to be applied to individual association roles.

> > > I see associations rather 'typed', i.e. not with too much varying r=
oles
> > > 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 develope=
r -
> > some applications would benefit from the freedom to be able to redefi=
ne
> > association structures and create new association structures on the f=
ly
> > (e.g. mind-mapping applications), whereas most applications requiring
> > interchange would find such freedom a problem.
>
> Can you think of an example?
>

If I am creating a topic map for rock groups, I would want topic types li=
ke=20
"Person", "Group", "Line-Up" and "Recording" with association types like=20
"Recorded", "Is Member Of". Now it could be argued that a person, group o=
r=20
line-up could play the role of "recording-artist" in the Recorded=20
association. But perhaps for consistency I want to only allow a Line-Up t=
o=20
play this role - so that my authors must create a Group topic, then creat=
e a=20
Line-Up and then state that a particular Line-Up of a Group recorded a=20
Recording. Thats a pretty fixed set of association structures, and I thin=
k=20
that it is a policy that you would agree with from a "programmer's viewpo=
int"=20
(even if you don't necessarily agree with the ontology). But perhaps some=
one=20
else would prefer to simply allow people to create their own links betwee=
n=20
groups, people, line-ups and recordings, perhaps creating new association=
=20
types as they go in a more anarchic manner - recreating something like a=20
Wiki-on-steroids or a the Everything2.com site.

> > > Of course it can. As soon as AsTMa! has a finite grammar (and it ha=
s),
> > > 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 c=
an
> > 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 construc=
ts.
>
> Even if that could be established, still a TM application has to
> "recognize" it has to do "the right thing".
>

Absolutely. But, if you can take a step back from the syntactic construct=
s and=20
create something of a higher level, then you can also allow a mapping fro=
m=20
the concepts to a variety of different syntaxes, and given that any=20
application dealing with a topic map constraint language is going to be=20
dealing with topic maps, a topic map abstraction seems like a reasonable =
way=20
to go...

Cheers,

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

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