[sc34wg3] TMCL issues

[Lars Marius Garshol]

* Michael Quaas
>
> Ok, that helps to understand the reasons for the current structure.
> Perhaps this should be explained somewhere, so that it is easier for
> newcomers to get into it. I could imagine some downside use cases with
> the proposed version and why it works better with the current one.

I suppose in theory we could, but in practice the highest priority has  
to be to finish TMCL itself, and at the moment that takes up quite a  
lot of time. So I'm afraid I personally don't think I have the time to  
do this.

> I find it more constistent when for example the plays-role template
> would look like this:
>  tmcl:constrained-topic-type(tmcl:constrains : ?c, tmcl:constrained :
> $tt)
>  tmcl:constrained-ASSOCIATION(tmcl:constrains : ?c,  
> tmcl:constrained : $at)
>  tmcl:constrained-role(tmcl:constrains : ?c, tmcl:constrained : $rt)
> instead of
>  tmcl:constrained-topic-type(tmcl:constrains : ?c, tmcl:constrained :
> $tt)
>  tmcl:constrained-STATEMENT(tmcl:constrains : ?c, tmcl:constrained :  
> $at)
>  tmcl:constrained-role(tmcl:constrains : ?c, tmcl:constrained : $rt)
> What do you think?

Ah, now I see. Well, we could of course do this, but the cost is that

  (a) we have to define yet another PSI and extend the schema with
      yet another association type, which people have to remember etc,

  (b) people have to remember that names and occurrences use
      constrained-statement, but associations, which are also
      statements, instead use constrained-association.

So I guess personally I think this would be harder to learn, and not  
easier.

> Assumed that I have an association-type parents-of which has the roles
> mother, father and optionally daughter and son. And I wanna allow only
> mother, father and daughter or mother, father and son as valid role
> combinations. How can I express that with the actual
> role-combination-constraint, where only a constrained-role and an
> other-constrained-role exists? Or am I missing something here?

You're not. You'll note that the rest of the sentence of which you  
only quoted the beginning said: "but that it only lets you define  
rules for
pairs of roles". And here you are asking for rules for three roles,  
and that's definitely not supported right now.

> In my opinion a role-combination-constraint should constrain exactly  
> one
> association and a nonempty set of role topic-type combinations.

Maybe so. The question is, how would you represent this in TMCL? Right  
now we reuse two existing association types for the first (role type,  
topic type) pair, and use two special ones for the second pair. But if  
there is an unlimited number of pairs, then what?

--Lars M.
http://www.garshol.priv.no/tmphoto/
http://www.garshol.priv.no/blog/