[sc34wg3] TMCL issues

[Lars Marius Garshol]

* Michael Quaas
>
> Yes. I'd like to propose to simplify the internal structure of the  
> TMCL
> schema (without changing its behavior).

I've registered this as an issue now:
   http://projects.topicmapslab.de/issues/1505

> Ok, as in general the number of real data is much higher than the
> number of the schema defining objects, this is not a strong  
> argument. So
> here's a better one.

Indeed. The argument from data size is not very strong, as you admit.

> In the current draft the procedure to find for instance all the name- 
> types of a topic-type looks like this:
>    1. get the counterplayers of the constrained-topic-type association
>    2. filter them by type topic-name-constraint
>    3. for each of them get the counterplayers of the
> constrained-statement association.
> In the proposed solution it would look like this:
>    1. get all counterplayers of the topic-name-constraint. Done.
> So it also reduces the complexity of the schema-queries. These are  
> used
> frequently by the UI-generator and its data validator.

This is true, but, really, we're just talking about reducing three  
lines of tolog to one. So the difference is not that great.

Graham and I had this very discussion a long time ago, with me  
suggesting the same thing that you do, and Graham arguing for the  
current structure. We use something very similar to what you propose  
in Ontopoly, but as 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.

Another downside is that it requires rewriting the whole  
specification, which I have to admit I'm not very eager to do.

So I'm not in favour of this, but would be interested to hear other  
opinions on the issue.

> Besides that I'd like to make some suggestions that might help  
> beginners
> to learn the language.
>    - rename topic-role-constraint in plays-role-constraint
>    - rename association-role-constraint in has-role-constraint

Made an issue for this, too:
   http://projects.topicmapslab.de/issues/1506

I'm personally more-or-less neutral on this. Any other opinions?

>    - add an constrained-associaion (after you've understood the whole
> tmcl-schema you see the advantage of using constrained-statement,  
> but at
> the beginning it's not very intuitiv)

I don't understand what you are suggesting here. Could you be a bit  
more explicit?

> A more general suggestion
>    - make it possible to constrain the role combinations for other  
> then
> binary associations

I made an issue for this as well:
   http://projects.topicmapslab.de/issues/1507

You'll note that the current role-combination-constraint already works  
for n-ary associations, but that it only lets you define rules for  
pairs of roles. I suppose one could in principle extend it to defining  
rules for n-tuples of roles, although I'm not sure what the ontology  
for that would look like. The question is whether this is really  
needed. Personally I'm not convinced that it is needed. Opinions  
welcome.

I'll work all these issues into the slides next week.

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