[sc34wg3] Subjects, role players, and user-defined association types

[Martin Bryan]

You got in early enough Sam ;-)

Steve N. suggested
>     We should decide what we want to do about this.  I
>     think there are several choices, including:
>
>     (1) We do nothing.  We don't say anything about it.
>         We pretend the issue doesn't exist, and we face
>         it at some later date.  (I think this is the
>         worst possible choice.  It weakens both the SAM
>         and our credibility.  It creates a situation in
>         which weeds will thrive.)
>
>     (2) We say that user-defined assertion types in
>         XTM/HyTM *are not* allowed to have any
>         semantics such that the subjects of any of
>         their role players are specified by instances
>         of such user-defined assertion types.
>
>         If we choose this option, whenever a topic map
>         author wants topics to be merged, he must say
>         so explicitly and redundantly, either with a
>         <topicRef> or with two <subjectIndicatorRef>s
>         to the same subject indicator.  Michel likes
>         this idea.  It protects developers of XTM/HyTM
>         processors from ever having to support
>         user-extensible merging rules, and it may have
>         other advantages of which I am not yet aware.
>         I dislike it because I think it should be
>         enough to say, in domain-specific terms (i.e.,
>         via instances of user-defined association
>         types), that topic A has subject S1, and topic
>         B has subject S1, and expect that A will merge
>         with B simply because they both have the same
>         subject.  It shouldn't *also* be necessary
>         to say explicitly:
>
>           (i) that topic A also has subject indicator
>               SI1, and topic B also has subject
>               indicator SI1, or
>
>          (ii) that topic A has the same subject as
>               topic B.
>
>         If the SAM imposes a requirement to supply such
>         redundant information in each topic map, we
>         will eventually have to answer the following
>         embarrassing question, emanating from possibly
>         irate users: "Why does XTM/HyTM allow
>         user-defined association types at all, since
>         they aren't allowed to mean anything in terms
>         of subject recognition?"
>
>     (3) We say that user-defined assertion types in
>         XTM/HyTM *are* allowed to have semantics such
>         that the subjects of their role players are
>         specified by instances of such user-defined
>         assertion types.  We require that, when such
>         topic maps are interchanged, they must include
>         the information necessary to allow such
>         subjects to be merged automatically, in the
>         normal course of topic map processing, whenever
>         such subjects are identical.
>
>         Personally, I strongly favor this third choice.

While sharing your preference for the third choice I would point out the
fallacy in the second choice, and the fact that there is, in fact, a halfway
house between them.

The fallacy in the second choice is that the topicRef and
subjectIndicatorRef are only needed at the point at which two maps need to
be merged. Until this point the maps could be maintained without these
pointers, providing there was some way of assigning these properties to any
mergeable exchanged topic map.

So what is the half-way house? Simply by saying that user-defined assertion
types are allowed, but that they must be transformed into topicRef or
subjectIndicatorRef pointers prior to exchange with another system.

Martin