[sc34wg3] revised draft Reference Model document N0298
Martin Bryan
sc34wg3@isotopicmaps.org
Sat, 13 Apr 2002 10:57:06 +0100
Steve
Thanks for taking the time to explain your thinking to me. I think the key
is the (somewhat incomplete) last sentence:
"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."
I say incomplete because I thing the words "of different types" should be
included after "several nodes".
I also think that there is another key problem in the overloading of the
term topic, as stated in:
'OK, then your operative definition of "topic" is not
the same as the draft Reference Model's operative
definition of "topic". '
Later in the same paragraph you introduce the concept of a "topic node". I
would strongly suggest that this term be adoped in the dRM to clearly
distinguish between an identifiable node in the dRM and an identifiable
topic in 13250.
I'm not sure that I understand how your topic-basename assertion type links
to the topic role statement in the preceding diagram. However, this is not
the cause of my problem, which is to do with the restrictions on whether the
same 13250 topic can be referenced as both an assertion type and a role
type. I quoted the example of a topic called "PublishedBy". This could be an
association type. Would this be a role for an assertion, or an assertion
type for the assertion? If the latter, then what is to stop the same topic
from being used as an occurrence role in another assertion.
Martin
----- Original Message -----
From: "Steven R. Newcomb" <srn@coolheads.com>
To: <sc34wg3@isotopicmaps.org>
Cc: "Patrice Ossona de Mendez" <pom@ehess.fr>; "Pascal Auillans"
<pascal.auillans@mondeca.com>
Sent: Friday, April 12, 2002 5:55 PM
Subject: Re: [sc34wg3] revised draft Reference Model document N0298
> "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
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>
>
>