[sc34wg3] New TMCL slides
Lars Marius Garshol
larsga at garshol.priv.no
Mon Nov 9 17:25:28 EST 2009
* Steve Newcomb
> Maybe Dmitry's requirements can be fulfilled without abandoning the
> "signatures" approach (I like Lars's "signatures" term).
For the record, Dmitry was the one to introduce the term "signature"
in this context.
> If we say that:
> Association Type T3 == ( role A, role B, role C)
> and additionally provide that role A must always be played (must
> have a role player), and that either role B or role C must be
> played, but not both, then, for whatever reasons Dmitry needs a
> single association type instead of two different ones, he can still
> have it, and for whatever reasons Lars Marius wants to preserve the
> "signatures" doctrine, it is still preserved.
Unfortunately, no. My "doctrine" is very strict: I don't want there to
be any optional roles in binary associations. That may sound simply
pig-headed, but there's a philosophical point underneath: TMDM defines
the association type as a topic which represents the nature of the
relationship between the subjects related by the association.
If there is a semantic difference between
association-type(role-a: foo, role-b: bar)
association-type(role-a: foo, role-c: bar)
then it is no longer true that the association type alone represents
the nature of the relationship between foo and bar. (And if there is
no semantic difference then there is no need to have three different
I can see a need for omissible role types in n-ary relationships where
it may be the case that one of the role players is not known, but in
binary relationship then if one of the players is not known you can
simply omit the entire relationship.
I should add that TMDM didn't define the concept of an association
type this way simply because it sounds nice. We really need a common
conception of what associations are and how they work. Years ago
people were thinking that
soccer-team(coach: a, player: b, player: c, player: d ...)
was perfectly acceptable modelling, but today that is thankfully no
longer the case.
As we narrow down the community view of the acceptable uses of
associations it becomes easier to write generic reusable software for
working with associations that can handle all topic maps.
In the case of the foo/bar association above, the Omnigator, the
Vizigator, and the Ontopia related-topics portlet would all treat
those two associations as being effectively the same. (Ontopoly would
not let you formulate the rule that the relationship could work this
way.) If they really are semantically different that would be bad.
So, in short, here is a use case that I can see absolutely no
practical use for, which complicates TMCL, and which makes it much
harder to write Topic Maps software. It might have some nice
philosophical properties, but to me personally that does not carry
> And there's another way to think about this, that *also* arguably
> serves both Dmitry's and Lars Marius's sensibilities:
> Association Type T4 == ( role A, role D)
> .... wherein the subject of role D is a subject which is the
> amalgamation of the subjects that were called role B and role C,
> above. Theoretically, at least, there's no problem in having a
> single subject which is the ambiguous amalgamation of other subjects
> that are individually regarded as distinct. Of course, the
> distinction between B and C is blurred in D, and if any
> disambiguation is needed between the two different senses of D, in
> the case of any particular association, that disambiguation will
> have to be supported by a means other than a distinction of role
> type. Seems complex, but the world is a complicated place, and the
> universes of semantics are far more complex still.
Sure, you could do this. And, yes, it would satisify me, because I
could have my strict doctrine of how associations work. I can't
imagine that it would satisfy Dmitry, though, because if it did it
would imply that his original concern was entirely frivolous.
Basically, either he would be requiring support for a non-existent
difference, or this proposal would lose information present in his
original topic map.
(I see below that you are not actually advocating this, so I'm
deleting the rest of my comments about this.)
> Serious topic maps should never tolerate exceptions to the "exactly
> one subject per topic" rule, and yet we sometimes openly tolerate it.
> Specifically, when we have two association types,
> Association Type T1 == ( role A, role B)
> Association Type T2 == ( role A, role C)
> ...the paramount rule that there can be only one subject per topic
> is violated.
> It's a violation because, if both T1 and T2 are defined, then role
> type A is necessarily forced to be a topic with two different
Now this is interesting, because it's the same as my argument, except
that you express it slightly differently.
Association Type T1 == ( role A, role B)
Association Type T1 == ( role A, role C) # note: T1, not T2
This requires T1 to be more than one type of relationship. (Yes,
arguably that A is more than one role, too. That's true, but I failed
to make that point above.)
> A: Well, it's true, what you say. In a few million years, none of
> this will make any difference, in all likelihood.
"In a hundred years everything will be forgotten." Knut Hamsun. And
very true it is.
> A: Yes. In my view, it should always be an error for a topic map, or
> a TMCL constraint, or any text or example in any part of the family
> of standards, to claim or imply that a single role type can appear
> in more than one association type. (My very first example, T1/T2
> above, is an example of an offending example.)
Graham and I have discussed this, and he's argued that it's a bad
thing to be using the same association role type in different
association types. I haven't really been convinced that that's the case.
You're really raising the issue now of whether we add a rule to TMCL
stating that the same association role type cannot be used in more
than one association type. (Ironically, if we do we'll have to redo
the entire TMCL ontology.)
> It's just not logically possible for that to be anything but an
> error, ever, unless maybe the association types are really the same
> anyway and we're really dealing with some kind of syntactic
> redundancy for which we have some tricky rule.
We do not have any such tricky rule in the standards.
More information about the sc34wg3