[sc34wg3] TMCL issues

[Michael Quaas]

Thank you Lars for the quick and presice answer.

> Graham and I had this very discussion a long time ago ...
That's what I imagined, but I couldn't find it in the archive.

> with me suggesting the same thing that you do ...
Phew! At least I'm not alone outside there. :-)

> Graham argued the structure you suggest is much  
> more irregular, and it becomes harder to attach non-TMCL information  
> to the schema. Personally I think extending TMCL with extra  
> information will be very common and useful, and now that I've gotten  
> used to it I really like the regularity of the current TMCL structure.
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.

>>    - add an constrained-associaion
> I don't understand what you are suggesting here. Could you be a bit  more explicit?
Topic-types play their constrained-topic-type "role", and role-types 
have a constrained-role. Association-types only get involved with the 
constrained-statement association. I think this is done to summarize 
some common behavior with name-types and occurrence-types (scope and 
reifier functionality). But as name-types and occurrence-types are only 
involved in "binary" constraints it is ok for them to "just" play the 
constrained-statement role (I know it's currently an association, but 
it's easier to express here). On the contrary association-types are 
involved with 3-ary constraints like the topic-role-constraint, where 
topic and role-types plays roles which easily identify them but 
association-types do not. 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?


> You'll note that the current role-combination-constraint already works  
> for n-ary associations
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?
In my opinion a role-combination-constraint should constrain exactly one 
association and a nonempty set of role topic-type combinations.

Best regards,
Michael Quaas