[topicmapmail] Inheriting Scope

[Murray Altheim]

Steven Hammond wrote:
> Hi there,
> 
> I'm starting to play around and try to understand topic maps and I''ve 
> got a question. Say, I have two associations, A and B, and B is an 
> instance of A. Now A has a scope X and B does not specify any scope. Is 
> B's scope X or unconstrained?

Steven,

There's no inherent inheritance in Topic Maps' conception of
Topics and Associations themselves. A Topic Map document is
a rather simple graph structure consisting of Topics and
Associations between Topics, and there's not many assumptions
one can make from that rather simple graph structure itself.

This is not to say that one couldn't define a set of conceptual
structures where transitivity and/or inheritance is stated as
part of a relation type, but this kind of thing would be
handled at a higher level than the core semantics of the Topic
Map document, basically at a schema level where a set of Topics
would be defined to create what is commonly called a computer-
based ontology. It would be at the schema or ontological level
that these things would be defined.

Now, one can use a Topic to type an Association, and it's the
combination of Topics and typed Associations where we can begin
to create those aforementioned "conceptual structures."

XTM 1.0 does define two Association types, superclass-subclass
and class-instance, and these could be considered relations
that function at the ontological level. In XTM 1.0 they're
rather underspecified compared to some schemas (by design, IMO),
e.g., we never went to great lengths to define tightly the
definition of a 'class.' We had unrealized plans to create what
at the time were called Association Templates, basically a way
of expressing a minimal schema language. With such a schema one
would also want to be able to express the schema's constraints
in a machine-processable way. This was considered outside of the
scope of what we had time to do with XTM 1.0, and work on these
kinds of features is currently underway within the ISO Topic
Maps committee.

The superclass-subclass relation is the kind used to create
what is commonly called a "subsumption hierarchy," where one
obtains the kind of inheritance you're after. There is a common
mistake in calling this an "is a" relation, which it is not.
The "is a" relation (called #$isa in the Cyc ontology) is the
class-instance relation, as in

    Fido is a dog.

Now, Fido inherits all of the characteristics of being a dog,
but Fido is not a class, he is an instance of the class "dog."
In the Cyc ontology, the subsumption hierarchy is formed out
of a collection framework, not a class framework, and it calls
its subsumptive relation #$genls (for "generalizes"). In my
own Ceryle project I call this the "kind of" relation, as in

   A dog is a kind of mammal.

Whereas in Cyc one might say "Mammal generalizes Dog" or
"Mammal is a supercollection of Dog" as in:

     (#$genls #$Dog #$Mammal)

In my experience, for many kinds of modeling, even those
systems that make claims for tight constraints (such as class
definitions) often break them in practice anyway. For example,
people promoting OWL often make great hay about its Description
Logics (DL) roots, and Pat Hayes (one of our preeminent
logicians, coming from outside the RDF community) has gone to
the trouble of retrospectively writing up some formal semantics
for RDF, but most of the implementations I've seen are
nonmonotonic and/or don't really pay much attention to these
formal definitions (if even their developers understand those
definitions). All of this formality is the kind of thing that
looks great on paper and gives pedants something to point at
during an argument (as we've seen quite recently), but it's the
kind of thing that can rightfully be called "academic" in the
derisive sense of that term.

People commonly mistake having a definition for following one.
Perhaps this is simply a matter of a system's users not having
the same understanding as the system's designers, but it also
is just a matter of mistaking computer-based ontologies as
something more than a form of human communication, as some kind
of statement of platonic ideals. Human communication is flawed,
and all ontologies are similarly flawed. There may be a
mathematical model behind them, but these systems are created
and used by people, and it's only through human interpretation
that we embue these systems with meaning. Another way of looking
at this is that all software has at least a few bugs, and
software isn't even that reliant on interpretations of natural
language.

I myself made this kind of error for a long time, as I had been
using XTM's superclass-subclass Association type when I really
(upon reflection) had developed a collection framework, similar
to the Cyc ontology, the system upon which I have taken most of
my inspiration. I was able to operate under this apparent
cognitive dissonance for several years without it bothering me
enough to notice. We all must take care to not mistake human
language that sounds formal for an actual formality in practice.

What we commonly do is use these systems until some error becomes
apparent, when someone's bank account goes haywire or the space
shuttle explodes. The information systems themselves don't "know"
any better, i.e., that the modeling concepts they express don't
match the real world. If you've seen The China Syndrome, this is
like when the nuclear power plant operator looks at an instrument
panel gauge and just "knows" it can't possibly be correct, so he
taps on its glass face with his finger until it pops up to the
"real" value. We should always be aware that our gauges might be
off, that our perceptions and interpretations of those perceptions
may not match the reality. What *really* is the value?

And just to clarify, when you state that one Association is an
instance of another, do you mean to say:

   * the typing Topic used to type Association B is either a
     subclass of the typing Topic of Association A

or

   * the typing Topic of association A is being used as the
     typing topic of association B.

I ask because Associations themselves don't have instances. An
Association type (i.e., a Topic used as a type for an Association)
can be an instance of a given class, but the Association itself
can't be considered a class (which would be required in order to
have instances in the traditional concept of a class-instance
relation).

This is probably more than you asked for; I hope it wasn't too
confusing.

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

   Bob did give me the secret to world domination, which was pretty
   startling. He looked at me and he said, "Don" (he called me Don),
   "think how dumb the average guy is." And I thought about that for
   a moment, and he said, "Half of them are dumber than that."
   http://www.austinchronicle.com/issues/vol17/issue47/screens.webb.html