[sc34wg3] TMCL issues
Lars Marius Garshol
larsga at garshol.priv.no
Fri Oct 30 08:09:05 EDT 2009
* Michael Quaas
> Yes. I'd like to propose to simplify the internal structure of the
> schema (without changing its behavior).
I've registered this as an issue now:
> 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
> 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
> 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:
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
> A more general suggestion
> - make it possible to constrain the role combinations for other
> binary associations
I made an issue for this as well:
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
I'll work all these issues into the slides next week.
More information about the sc34wg3