[sc34wg3] Scope, again
Steven R. Newcomb
sc34wg3@isotopicmaps.org
27 Nov 2002 12:23:27 -0600
I presented the following ideas about scope at our
meeting in Montreal, and I think they bear repeating
here.
My own understanding of scope is based on the RM idea
that every relationship between two or more subjects
is, fundamentally, a relationship like any other
relationship. And there isn't anything going on in
topic maps other than relationships between topics
(subjects).
XTM syntax hides the homomorphism of all relationships,
and that's a good thing. The draft RM reveals this
homomorphism, and that, too, is a good thing.
In the RM, therefore, the relationships between a
subject and each of its occurrences is just a
relationship, like any other:
topic-occurrence
(T)
topic | occurrence
(R) | (R)
| | |
| | |
(x)--------(C)--------(A)--------(C)--------(x)
subject S S has piece of
occurrence P addressable
information P
In the RM, even the relationships between a subject and
each of its names is just a relationship:
topic-name
(T)
topic | name
(R) | (R)
| | |
| | |
(x)--------(C)--------(A)--------(C)--------(x)
subject S S has name N
name N
And all other relationships between all other subjects,
regardless of how they are expressed syntactically
(such as, in XTM, via <association> <type>, etc.) have
the same structure, too.
Now:
All relationships can themselves be role players in
other relationships. When this happens, something is
being said *about* the relationship. If John and Mary
are asserted to be married:
husband-wife
(T)
husband | wife
(R) | (R)
| | |
| | |
(x)--------(C)--------(A)--------(C)--------(x)
John John and Mary
Mary are married
.. then another assertion can say, about their marriage,
that it's a happy one:
class-instance
(T)
instance | class
(R) | (R)
| | |
| | |
(A)--------(C)--------(A)--------(C)--------(x)
John and John's and happy human
Mary are married Mary's marriage relationships
(only the a-node is a happy one
of this assertion
is shown here)
What does all this have to do with scope?
Scope is nothing more or less than a catchall
relationship type that's the easiest, handiest, and
laziest way to characterize relationships:
topic-scope
(T)
topic | scope
(R) | (R)
| | |
| | |
(A)--------(C)--------(A)--------(C)--------(x)
John and John's and set of
Mary are married Mary's marriage subjects S
is characterized
by set S
It's a way for topic map users to avoid having to
define a bunch of relationship types just so they can
characterize relationships.
The most precise way to characterize a relationship is
by saying exactly what you mean about it, using a
relationship type that's designed for the purpose of
making that kind of statement. But that's a utopian
ideal; it's not congruent with the human condition, nor
with human nature. None of us will live long enough to
provide a definitional foundation for everything we
want to say, and few of us have the patience to listen
to anybody who wants to try.
Consider, for example, the relationships between names
and named subjects. When we want to give a name to a
thing, we just want to do that, and we don't want to
have to think for a long time about all the limitations
on the, uh, scope of the relationship between the name
and the named thing. All we really want to do (if we
even want to do that much) is to establish different
namespaces, so that multiple subjects can have the same
name without losing our ability to address those
subjects unambiguously by means of their names.
So, the topic-scope relationship type (see above diagram
for an instance of one) allows us, basically, to paste
any number of sets of labels on any relationship,
without having first to define a more precise way to
say what we mean. (But "labels" isn't the right word,
because each "label" is a subject.)
For me, that's what scope is all about, and,
fundamentally, that's *all* it's about. Now, why is
the scoping facility so important for topic maps?
During the lifetime of a growing and changing topic
map, scopes can be used to characterize relationships
whenever there's no defined relationship type that
would allow us to say exactly what we mean. A scope,
therefore, is like a shopping list of semi-explicit
nuances.
>From time to time, the maintainers of a topic map will
notice that some of its scopes are getting big, ugly,
repetitious, ambiguous, and/or difficult to interpret.
When that happens, they will then clear up the
situation by defining some relationship-characterizing
relationship types that had been only implicit in the
scopes. In each case, they will remove one or more
members from a scope, and they will cause those those
former scope members to be roleplayers in new,
precisely-defined relationships that will also have the
characterized assertions as other roleplayers. This
doesn't mean that the scopes go away; it merely means
that, from time to time, they get pruned. They become
smaller sets of topics that are more understandable and
simpler to process.
I think the scope facility is vital. It allows us to
continue the work of creating a topic map, even when we
discover that we don't have all the tools -- the
defined relationship types -- that we need. The truth
is, we will never have all the relationship types that
need in order to capture all the nuances that we need
to capture. Therefore, scope is one of the *key*
features of the topic maps paradigm. It makes topic
mapping practical for ordinary mortals, instead of
being reserved only for philosopher-supermen who
somehow know in advance everything about the knowledge
that they're attempting to manage.
Some have proposed that scope should not be defined in
the SAM, but I oppose this view. I think the SAM is
exactly the right place to define it. I hope and
believe that the SAM will be the foundation of most, if
not all, Topic Maps Applications. I believe that the
SAM is where we should capture the lore that we in the
Topic Maps community have developed about knowledge
management. Scope is a significant and valuable part
of that practical lore.
On the other hand, I have no objection to the idea of
making the scope facility a separately-borrowable
module of the SAM. (In fact, from a design
perspective, that's a good idea, but really it all
depends on what we want to do. To modularize the SAM
may or may not be better for the development of the
topic maps market, and we're still in its early days,
here. This is a BIG ISSUE that deserves careful
thought on everyone's part, with special consideration
given to those who have invested in business plans that
might be affected one way or the other.)
There will always be many different philosophies about
how to use scope. I would caution against defining
such a philosophy in the SAM, because that would limit
the applicability of the SAM, possibly making it
downright unpopular.
Some have proposed that scopes should have structure,
instead of just being a sets of
otherwise-undifferentiated topics. I would caution
against inventing anything new in order to accomplish
this, for at least three reasons:
(1) At the RM level, we already have everything we need
to do this. We don't need to invent anything new.
Simply make assertions about the subjects that are
in the scopes. If that's not a sharp-enough
scalpel, make assertions about the set-member
assertions that establish those topics' memberships
in specific scopes. The only question is whether
we want to enable such assertions to be made at the
level of the XTM or HyTM syntaxes. (We can
certainly do that, but I think it's not a good
idea; see next reason.)
(2) If our scopes are getting so big, ugly, and complex
that we need to structure them, that should be a
signal that what we *really* need to do is to
define more specialized ways of characterizing
relationships. In other words, we should define
more assertion-characterizing assertion types, in
order to relieve our scopes of some of their
semantic overload.
(3) If we add internal structure to scopes, the
complexity of establishing namespaces by means of
scope increases dramatically. If two scopes have
the same set of subjects, but different internal
substructures, are they the same, or not? I'm very
leery of this idea of "structured scopes", because,
in the end, I think they would really have to be
just little encapsulated topic maps that are
somehow excused from participation in the larger
topic map. This is a bad idea because it dishonors
the Subject Location Uniqueness Objective.
***
P. S. Much has been said (most recently by Marc de
Graauw, but also by others) about the fact that
in 13250, the scoping facility has divergent
purposes. I think that's certainly true, and I'm
not sure that it's a bad thing. However, if we
think it's a bad thing, we can correct it by
defining, in the SAM, more than just a single
underlying kind of scoping assertion type. We
can define a special assertion type that's only
used to establish topic namespaces, for example.
(Something else to think about.)
-- 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