[sc34wg3] revised draft Reference Model document N0298

Steven R. Newcomb sc34wg3@isotopicmaps.org
12 Apr 2002 11:55:45 -0500


"Martin Bryan" <mtbryan@sgml.u-net.com> writes:

> Let me try to make the case clearer as you seem to
> have missed the essence of it. The case I am thinking
> of is the one where the occrl attribute has an
> implied value (i.e. the GI) which is associated via
> the type attribute with the identifier of a
> particular topic (whose base names happen to serve as
> its name, but the name part is irrelevant in this
> issue)

> I don't claim to fully understand what an assertion
> is, or how the word topic is restriced within
> SAM. When I use the word topic I mean the object with
> a unique identifier that can be used to find out
> information such as the base name and alternative
> names that can be displayed to users.

OK, then your operative definition of "topic" is not
the same as the draft Reference Model's operative
definition of "topic".  In the dRM, topics don't have
unique identifiers.  (In *implementations* of the dRM,
topic nodes might have unique identifiers; there are no
constraints on how implementations represent topics and
assertions internally.)  However, in the dRM, as you
suggest, topic nodes are indeed "used to find out
information such as the base name"; they are role
players in assertions that assert that they have names.

> As I understand 13250 there is an implied link from
> the GI name (not itself a topic)

(The draft Reference Model regards all names of all
topics as topics themselves.)

> of the occurrence to the identifier of the topic
> referenced by the type attribute.

(The draft Reference Model's topics don't have
identifiers; all need for identifiers has been erased
by instantiating direct connections (assertions) with
the things that would otherwise have to be
*referenced*.  Since the dRM exists at a plane where
there's no referencing, it has no use for identifiers.)

> This topic identifies the role that the occurrence is
> playing and, I therefore consider, should be used as
> the R node in your model.

I agree with you, there!

> You state that:
> A: The name specified via the generic identifier can
>    become the subject of a topic (let's call it the
>    "name topic").  By means of a naming assertion, the
>    name topic's subject can be asserted to be a name of
>    the topic whose subject is the occurrence role.

> This implies that the software has to create a
> "naming assertion" that states that the name of the
> occrl is the name of the GI. But this loses the fact
> that the type attribute states clearly which topic
> contains the naming assertions associated with the
> occrl.

>From my perspective, you appear to be using the
operative definition of "topic", as we use the term in
the context of 13250 syntax (i.e., a "topic" is the
combination of things stated in a <topic>).  That
definition doesn't work when we're talking about the
draft Reference Model.  The draft Reference Model's
operative definition of "topic" is "a node that is the
unique surrogate of exactly one subject of
conversation".

In the dRM, "topics" cannot "contain naming
assertions".  Instead, topics that have names play
roles in naming assertions.  In the dRM, a "topic" is
nothing more or less than a node that is the endpoint
of zero or more arcs.  (Well, some nodes are a little
bit more than an endpoint of zero or more arcs; if a
node's subject is a piece of addressable information,
that addressable information is its property.)

Let me try again.  Before we discuss how we might
transform an instance of an occurrence declaration in
13250 syntax into an equivalent dRM graph phenomena,
let's first understand what an occurrence looks like at
the dRM level.  At the dRM level, let's say that
subject A has an occurrence which is subject B.
(Occurrences are always addressable pieces of
information, so subject B is an addressable subject,
and it's therefore represented as a (topic) node that
has, as its only dRM-defined property, the piece of
addressable information that is the occurrence.)  Now
let's imagine that we've defined an assertion type to
represent our particular kind of occurrence, called
"topic-occurrence".  This assertion type has two roles:

  (1) the subject that plays the "topic" role is the
      subject that *has* the occurrence, and

  (2) the subject that plays the "occurrence" role is
      the addressable piece of information that *is*
      the occurrence of our particular type of
      occurrence.

(In the diagram below, each node is represented as a
lowercase o:)


    topic-occurrence
     assertion type
           o
           |
    topic  |  occurrence
    role   |    role
      o    |     o
o-----|----|-----|----o  
A                     B ............ (occurrence data)
                         (property)


Now let's focus our attention on the node whose subject
is the "occurrence role" in the above-diagrammed
assertion:

             occurrence
               role
                 o
              ---|---

You've quoted me as saying:

> A: The name specified via the generic identifier can
>    become the subject of a topic (let's call it the
>    "name topic").  By means of a naming assertion, the
>    name topic's subject can be asserted to be a name of
>    the topic whose subject is the occurrence role.

Here's what I was trying to say when I said that.  In
addition to being the occurrence role topic in the
assertion diagrammed above, that very same topic is
also a role *player* in the assertion diagrammed below,
which asserts that this particular role has a
particular name:
               
              topic-basename
              assertion type
                   o
                   |
            topic  |   basename
occurrence  role   |     role
    role     o     |      o
      o------|-----|------|------o
  (now also                    the "name topic"
  *playing*                    whose subject is
  a role in                    the name of the
  this other                   occurrence role
  assertion)                   (which, in HyTM,
                               may be the GI of
                               the <occrl>)

> As Graham Moore has pointed out there is a problem
> with SAM in that it uses names as a replacement for
> identifiers. My problem is that I think (possibly
> mistakenly) that the identifier of the topic pointed
> to by the type attribute of an occurs element could
> also find itself being used as an assertion in some
> other context. Yet your rules would make this
> impossible.

Again, at the dRM level, all syntactic object
identifiers, and all references to them, have
disappeared.  Their various significances are
represented by combinations of arcs and nodes --
assertions.

I don't understand your remark:

   > "the identifier of the topic pointed to by the
   > type attribute of an occurs element could also
   > find itself being used as an assertion in some
   > other context.

I can understand how a reference to an identifier, in
combination with the identifier being referenced, would
be represented in dRM terms as an assertion in which
the referencer and the referenced thing both play
roles.  But I don't understand how an "identifier"
could be "used as an assertion in some other context".
Sorry, Martin, I'm really struggling, here.

> You state "It's logically impossible for a single
> subject to be any combination of them." This implies
> that there needs to be two of what you call subjects
> if the same topic is being used as both a role of an
> occurrence and as an assertion in another
> operation.

I don't see how a *single* subject of conversation can
be *both* a role (in some class of relationships) *and*
an assertion (a relationship).  There is a big
difference between these two kinds of things.  For
example, a role is a *class* (which is one of the
reasons why 13250 calls it a "role type"), while a
relationship is an *instance* (in which specific role
players play role types in an instance of a type of
relationship).

> I am trying to clarify under what conditions a
> uniquely identified 13250 topic can be represented by
> more than one node type in a SAM.

I'm not sure I know what you mean when you say "node
type", or when you say "a SAM".  However, I can say
this much with certainty: a single 13250 <topic> can
demand the existence of several nodes and several
assertions at the dRM graph level.

-- Steve

Steven R. Newcomb, Consultant
srn@coolheads.com

Coolheads Consulting
http://www.coolheads.com

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

1527 Northaven Drive
Allen, Texas 75002-1648 USA