[sc34wg3] SAM-issue term-scope-def

[Marc de Graauw]

Lars Marius Garshol

> Meanwhile, we need to decide what to do in the short term. I am
> leaning towards specifying that scope is an intersection. Bernard
> would like to see it left undefined.
>
> I would like to hear other opinions on this. If I don't get any I will
> do intersection for now, and we can discuss this in Montréal.
>

The terminology is not a happy one. Intersection and union are things one does
with sets. Scope is a set of topics, but when we say that a scope Finland,
Norway is an intersection (or union) we are applying intersection (union) to
the topics Finland and Norway, and those topics are not (necessarily) sets.
(This is not something I came up with, Steve Newcomb noted it too long ago,
and problably others too). So one cannot really say that scope is either a
union or an intersection.

The basic idea behind it is clear though. In some way a scoping topic applies
within a certain context, and the topic characteristic assignment is valid
when that scoping topic applies. So if we have topic X with name Y which is
scoped by topic A, then Y is a valid name whenever A applies.

When we refrase scope-as-union in this way we get:
if we have topic X with name Y which is scoped by topics A and B, then Y is a
valid name whenever A applies _or_ B applies

When we refrase scope-as-intersection we get:
if we have topic X with name Y which is scoped by topics A and B, then Y is a
valid name whenever A applies _and_ B applies

What 'applies' really means is not relevant, this is basically up to the
application (or user) of the Topic Map. However, if an application wants to do
something useful with scope it has to decide whether a scoping topic 'applies'
or not - at least I can see not other way to do anything with scope.

SAM says:
"Formally, a scope is composed of a set of subjects that together define the
context. That is, the statement is considered valid only in contexts where all
the subjects in the scope apply. In a sense, the scope is made up of the
intersection of the subjects it is composed of."

Is suggest we drop the terms 'union' and 'intersection' altogether and change
the SAM to:

"Formally, a scope is composed of a set of subjects that together define the
context. That is, the statement is considered valid only in contexts where all
the subjects in the scope apply."

when we choose what was previously called the 'intersection'-view, which might
more approriately be called the 'all subjects' view.
Likewise it could be changed to:

"Formally, a scope is composed of a set of subjects that together define the
context. That is, the statement is considered valid only in contexts where any
one of the subjects in the scope applies."

when we choose what was previously called the 'union'-view, which we could
call the 'any subject' view.

Furthermore, I suggest the word 'only' should be dropped. When we say  topic
name 'economie' is valid in when the scoping topic 'Dutch' applies,  we surely
do not intend to say this name is valid _only_ in Dutch. What we assert is
that it is valid in Dutch, and we do not really say anything about its
validity outside this context. (In other words, it is quite possible that
other languages use the same word for this topic.)

I do not have very strong opinions on the all-subjects or any-subject views. I
surely agree that in the former case the unconstrained scope should be the
empty set and in the latter one the set of all topics - or some similar
construct, such as Martin proposes. For me, as a Topic Map author, either way
would work. It seems the any-subject view is compatible with ISO13250 (but
phrased better), and the all-subject view is easier implementable for Topic
Map application vendors since it avoids the set of all topics.  I would tend
to the any-subject view for backward compatibility if there is a reasonable
way around the problems with the set of all topics (or similar contructs).
Since I do not implement Topic Map applications I have no idea whether there
is such a reasonable way or not.

I certainly do agree with a lot of others that scope should be strengthened
and needs some internal structure. I certainly do not think it is useless as
it is, but its applicability is limited.

Marc