Standards » TMCL

Will try and do a proposal that binds the variant constraint to name types.

Naito-san posted some use cases: http://www.infoloom.com/pipermail/topicmapmail/2009q2/007497.html

Xûan has another, which basically amounts to sort names: http://www.infoloom.com/pipermail/topicmapmail/2009q2/007483.html

def has-variant($nt, $scopetype, $min, $max)
  ?c isa tmcl:variant-constraint;
    tmcl:card-min: $min;
    tmcl:card-max: $max.

  tmcl:constrained-statement(tmcl:constrains : ?c, tmcl:constrained : $nt)
  tmcl:constrained-scope(tmcl:constrains : ?c, tmcl:constrained : $scopetype)
end

realName isa tmcl:name-type;
  - "Real name";
  has-variant(hiragana, 1, 1);
  has-variant(romaji, 1, 1).

We might add a variant-scope-constraint, variant-reifier-constraint, variant-unique-value-constraint, and variant-regular-expression-constraint where we use the tmcl:constrained-scope to say which variants are constrained (it's those which have topics of this type in their scope).

Thus one could probably say:

  reading isa transliteration-type.
  hiragana isa script.
  romaji isa script.

  realName isa tmcl:name-type;
    - "Real name";
    has-variant(script, 0, *).

  script
    has-variant-scope(transliteration-type, 1, 1).

1. has-variant-scope can only be attached to the type of scoping topic used in has-variant, but it looks out of place there, as scripts may well be normal topics in their own right.
2. realName may well have variants scoped with script and transliteration-type, but it's not a given that all variants scoped with script are also scoped with transliteration-type.
3. it would be better to be able to say directly that variants of realName must be scoped with one script and one transliteration-type.
4. are the scoping rules here really expressible via topic type? or should we say that realName must be scoped with one script and the topic "reading"?

It's not easy to see how to approach this, given that we have so few
use cases and so little real experience with this.

Note that many of these problems recur for issue 868:
http://projects.topicmapslab.de/issues/868

The Leipzig meeting noted:

This proposal is underpowered. It cannot express different cardinalities for
the different topics appearing on different variants. 
Suggested that this compromise of ‘one scope’ supported would be acceptable
in order to advance the completion of standard.

Question from the Leipzig meeting:

Do we need $tt for variant constraints, wouldn’t they be consistent across all uses
of the name type, regardless of topic type?

Lars Marius Garshol schrieb:

We now have a concrete proposal:

[...]

We'll put this proposal into the next draft, even though we realize that it is underpowered. The problem is that doing something more complete would be highly complex and bloat the standard too much compared to its utility.

Regarding the question from the Leipzig meeting about $tt: the $tt is needed because very often $nt will be tmdm:topic-name, and so there will be different rules for different topic types. If one wants a global rule $tt can be set to tmdm:subject.