Re: [xtm-wg] Issue with instanceOf

["Steven R. Newcomb" <srn@coolheads.com>]

[Peter Jones:]
> In a scope construct, you make references to topics. Those topics
> might have associations between them, so those are additional
> properties of the scope.

A scope is a set of topics.  A scope is not a set of references to
topics; it's a set of topics, full stop.  It's true that,
syntactically, we refer to the topics in order to indicate that they
participate in scopes.  But that's just syntax -- the mechanical
aspects of interchanging the information as to which topics
participate in which scopes.  What the syntax *means* is that the
topics participate in scopes; they are members of the sets of topics,
each set of which constitutes a scope.

Regardless of whether or not they participate in scopes, all topics
consist of characteristics (names, occurrences, roles played in
associations).  From the perspective of a scope, however, none of the
characteristics are directly visible.  The situation is similar to the
way in which we see far-off planetary systems from our perspective in
our corner of our galaxy: we don't see the planets (the
characteristics).  We only see the stars that mark the centers of
planetary systems (topics).  If we want to see the planets that orbit
one of these stars, we aim our spaceship at that star and go there.
When we arrive there, then we're in a position to see the planets.  A
scope is like a set of stars -- the stars have planets, but we can
only see the stars, and they're all we need to see.

> With the HUGE caveat that I haven't read the processing model stuff
> yet...

Ah.  You'll be interested in reading the draft processing model,
especially in the light of the below remarks.

> Should the contents of instanceOf _ever_ be unscoped (whether
> unconstrained or not), strictly speaking?

Lots of things to be said here.

(1) There is no such thing as an unscoped association.  There is, of
    course, the possibility that the scope is the null set of topics
    (called "the unconstrained scope").

(2) The drafting of the processing model revealed that there must be
    two distinct ways of handling class-instance-ness in the graph
    because of a combination of two constraints:

    (a) the absolute requirement that associations, including
        class-instance associations, be templatable, and

    (b) the absolute impossibility of specifying, by means of
        class-instance *associations*, that associations are instances
        of association templates, due to infinite regress.

    The solution used in the processing model was to provide a special
    arc type for the kind of class-instance-ness that exists between
    an association template and an association that (presumably)
    conforms to the template (the "association template" arc type).
    Each such arc connects an a-node (representing an association) to
    its template, represented by a t-node.

(3) In the graph, *only* associations (a-nodes) have scope, and
    a-nodes *always* have scope.  In the graph, names (which have
    themselves become t-nodes) are connected to topics by means of
    a-nodes whose template is defined in the Spec.  Occurrences (which
    have themselves become t-nodes) are connected to topics by means
    of a-nodes whose template is defined in the Spec.  And, of course,
    <association>s are represented as a-nodes.  Their templates, if
    any, can be defined by the topic map author.

(4) Every a-node is connected to the topics that participate in the
    association that the a-node represents by means of "association
    member" arcs.  Every a-node is connected to the scope (s-node) of
    the association represented by the a-node by means of an
    "association scope" arc.  The a-node is regarded as "having" the
    scope represented by the s-node.  Arcs *do not* have scope.  Only
    a-nodes have scope.

(5) Back to #2, above, the "association template" arc type.  Remember:
    arcs do not have scope; and they are not associations.  So, in
    answer to your question, "Should the contents of <instanceOf>
    _ever_ be unscoped", the answer is that it depends on whether the
    XTM Specification, and particularly the processing model, 

    (a) specifies that an <instanceOf> child of <association> creates
        an "association template" arc, or

    (b) specifies that an <instanceOf> child of <association> creates
        a class-instance a-node whose scope is the null set of topics
        (the "unconstrained scope"), just as it does when <instanceOf>
        is the child of <topic>.

    Since the processing model and the explanation of the syntax are
    still in draft form, we have options.  There are at least two
    reasonable possibilities that I can think of:

       i. When <instanceOf> appears in <association>, it always
          creates an "association template" arc that connects the
          a-node that represents the <association> to the t-node that
          represents the template, and that was effectively referenced
          by the <instanceOf>.

          The main downside of this idea is that <instanceOf> will do
          an entirely different thing when it is the child of a
          <topic> than when it is the child of an <association>.  That
          is a violation of our excellent doctrine that elements with
          the same generic identifiers should always do the same
          things (as Daniel has already pointed out, in response to
          Peter Newcomb's note).  Personally, I'd prefer to keep
          <instanceOf> just as it is: shorthand for a class-instance
          association with unconstrained (null set of topics) scope.

          Does it make sense for an association to be an instance of
          something other than a template?  Yes, I believe so.  For
          example, the marriage of John and Mary may conform to the
          constraints of a template for marriage associations, and, at
          the same time, the marriage of John and Mary can be an
          instance of a bad idea (because the topic map author
          believes, e.g., that John and Mary are incompatible, or that
          the marriage will end in bloodshed, or that Mary will be
          bored to death).

      ii. Add a new element type to the content model of
          <association>, the purpose of which is to refer to a
          template, and that will demand the existence of an
          "association template" arc in the graph.  I think Daniel has
          proposed <associationSpec> as the generic identifier of such
          an element type.

          (By the way, adding such a new element type will not violate
          the "locked-down" status of the existing DTD, because it
          will not invalidate any existing XTM topic map.)

----------------------------------------------------------------------

Here are some miscellaneous remarks that have helped other readers of
the Processing Model draft:

There isn't really much difference between a t-node (a topic node) and
an a-node (an association node).  Both t-nodes and a-nodes can serve
as the "member" end of any number of "association member" arcs.  But
the difference between the two is crucial:

* If a node serves as the "association" end of any 

  - "association member" arc, 

  - "association scope" arc, or

  - "association template" arc,

  it's an a-node, by definition.  (And therefore it *must* serve as
  the "association" end of at least one "association scope" arc.)  If
  not, and if it's not an s-node (which is a completely different
  animal), it's a t-node.

* If a node serves as the "template" end of any "association template"
  arc, it must be a t-node; it cannot be an a-node.

Equivalents of the above statements are in the PM draft already, but
conversations with several people have indicated that they could be a
lot more explicit.  Also: I wholeheartedly agree with several
complaints that the processing model needs some diagrams.  I think
Sam is drafting some, and so am I.

-Steve

--
Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

405 Flagler Court
Allen, Texas 75013-2821 USA

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com