[sc34wg3] New TMCL slides

[Lars Marius Garshol]

* 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)

and

   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  
role types.)

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  
much weight.

> 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.)

> <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.)

> 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.

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