[sc34wg3] New TMCL slides: pinging LMG's intuition about role-type subjects

Steve Newcomb srn at coolheads.com
Mon Nov 23 13:19:28 EST 2009

>> <howl>
>> 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 subjects.
> 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.)
If I had my way, I'd make "association type" a redundant way of saying 
"signature", as Patrick and I demonstrated in 
You'd still need association type topics, in order to talk about them, 
but each association-type-topic's subject identity would be nothing more 
or less than a set of role-types, and each such set would be required to 
be disjunct from all others. This seems the cleanest way forward, to me. 
It makes less work into more benefit, while respecting the 
one-subject-per-topic constraint.

(But, obviously, cleanliness is not the only criterion relevant to the 
making of standards, the best must not be allowed to drive out the good, 
and existing investments have real value that must be conserved wherever 
>> 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.
Let me try to ping your intuition about this (which is a tricky thing to 
attempt, so I wish myself good luck here).

The identity of a set is the gestalt of its members. If we change any 
member, or add a member, or remove a member, the identity of the set is 
different. We say, "It's not the same set any more." Because it's not! 
Anybody who understands what a "set" is intuitively knows that two set 
expressions that specify the same members in fact represent the same 
set, and that, conversely, two set expressions that specify different 
members represent different sets. This is inherent in the definition of 
"set", and in the semantics of "set expressions", regardless of their 
syntax, and regardless of the order in which the members of sets are 
specified by such expressions. The fact that "set expressions" 
invariably impose some order on the specification of the members is an 
artifact of the time-boundedness of communications, but the sets 
themselves are quite real apart from any way of expressing them. The 
nature of their reality is order-independent, despite the fact that 
there is no way we can express them without imposing some order on them. 
Somewhere, we have to explain the semantics of our set expressions, and 
our explanation must include a disclaimer to the effect of, "Pay no 
attention to the order given here. That's just syntactic trickery, or 
poetry, or something. Even though, here, we're apparently specifying a 
list of different things, the *gestalt* to which each of them 
contributes its identity is what we're talking about. We're talking 
about the involvement of these specific things in something (a "set") 
that is other than themselves, but whose identity is neither more nor 
less than the collection of the identities of these specific things.

A relationship, like a set, is also a *gestalt*. It is what it is 
because of what its role-types and roleplayers are, and because of which 
role-types are played by which roleplayers. That's the reason why, in 
Topic Maps, we model relationships as sets of role-type/roleplayer 
pairs. If we have two associations in front of us, and the two are 
different with respect to any member(s) of their constituent 
role-type/roleplayer pairs, we say, "The subjects of these two 
associations are not the same; their subjects are *different* 
relationships." (Well, uh, after merging, they may turn out to be the 
same, after all, so let's assume, for all purposes of this discussion, 
that merging is already complete before we make the comparison of the 
two sets of role-type/roleplayer pairs.)

Now let's do a thought experiment. Let's consider an association, and 
the relationship which is its subject. Let's ask, "What *kind* of 
association is this?" Well, for me, anyway, it's intuitively obvious 
that the *kind* of an association is nothing more or less than the set 
of the role-types that can be played in an instance of such a kind. The 
procedure for instantiating a kind of relationship, such as marriage, is 
to endow at least two of the role-types (of the set of role-types that 
comprises a particular kind of relationship) with actual roleplayers, 
such as George and Mary.

Here's where I attempt to ping your intuition; all the foregoing was 
preparation for it.

The set of role-types that constitutes a *kind* of relationship is a 
gestalt (like any other set), but it has a special feature: it specifies 
the nature of the relatednesses of the roleplayers that appear in its 
instances. These relatednesses are also a set. For example, consider the 
following association:

association_type_name: transaction (
value_from_buyer_to_seller: $21.50,
value_from_seller_to_buyer: a_simulated_gold_watch,

The above association, like any other relationship, is akin to a 
philosophical dialectic, in that nothing is optional. In other words, 
there's no relationship unless all four roles are played. Each member of 
the set of relatednesses in this association have the same quality of 

(1) Mike and Patty have a buyer-seller relatedness.
(2) Mike and value_from_buyer_to_seller are related by virtue of the 
fact that the roleplayer of the value_from_buyer_to_seller, $21.50, is 
Mike's before the transaction, and is necessarily surrendered by Mike in 
order that the transaction can exist.
(3) Mike and the value_from_seller_to_buyer are related by virtue of the 
fact that Mike's desire for a_simulated_gold_watch is a necessary 
precondition to the existence of the transaction, and by virtue of the 
fact that during the course of the transaction, Mike takes possession of it.
(4) Patty wants $21.50, and she takes possession of it.
(5) Patty has a simulated_gold_watch, wants to sell it, and surrenders it.
(6) $21.50 and a_simulated_gold_watch are related by virtue of the fact 
that both Mike and Patty agree, and act upon, their conviction that they 
are worth trading for each other, at least from their personal perspectives.

I've written down all this obvious stuff in order to demonstrate that :

/The essential nature of each role depends on, and is inseparable from, 
the nature of all the other roles, individually, and the nature of the 
complete set of roles, collectively.

"Buyer" is what it is because of what "seller" and 
"value_from_buyer_to_seller" and "value_from_seller_to_buyer" are.
"Seller" is what it is because of what "buyer" and 
"value_from_buyer_to_seller" and "value_from_seller_to_buyer" are.

A "transaction" is what it is because there's a buyer, a seller, and an 
exchange of valuable consideration between them.
"Buyer" is what it is because of what "buyer", "seller", 
"value_from_buyer_to_seller", and "value_from_seller_to_buyer" 
collectively are, i.e. a type of relationship in which valuable 
considerations are exchanged.
"Seller" is...(ditto)
/So, if the role "buyer" (as reified by a topic we'll call "buyer") 
appears in another *kind* (type) of relationship -- i.e., one that is 
characterizable as a different set of role types -- then that topic must 
have two different subjects. And that's forbidden in topic maps. If we 
start to wink at topics that have more than one subject, all is lost, it 
seems to me.
> 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.)
Seems like a high price, doesn't it? Of course I'm arguing that the 
price should be paid, but it's easy for me to argue for improvement 
because the existing investments in that ontology were not made by me. 
(I personally would rather be correct than rich, but I recognize that 
there are other arguably-valid attitudes about that kind of question, 
and poverty has little to recommend it.)

This seems like a pretty fundamental question to me. Is there no other 
way forward? How important is one-subject-per-topic to the community? 
How important is it that Topic Maps has a shared understanding of the 
semantics of associations, and the semantics of association types, as 
being relationships and kinds of relationships, respectively? These 
things are very important to me, but not necessarily important to others.
>> 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.
It's useful to propose trickinesses and weasel-wordings in discussions, 
though. It's a way to give everybody the horrors, for one thing. And 
sometimes there's just no other way to retain some semblance of 
integrity and, at the same time, to move forward and do what needs to be 
done. I can imagine Charles Goldfarb chuckling in an I-told-you-so 
manner as I write these pragmatic words, but I'm hopeful that we have 
not backed ourselves into *that* kind of corner, at least not yet. 
Tricks should be the very last resort, I think.

All best wishes and good luck to us all,


More information about the sc34wg3 mailing list