[sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep')

[Marc de Graauw]

I have raised an issue in private conversation with Lars on the unconstrained 
scope, now listed as "scope-unconstrained-rep". Description: "How should the 
unconstrained scope be represented? Essentially, it is the scope made up of all 
subjects, that is, the universal set.". I would like to expand on this. (Since 
this is an old issue, it was probably raised by others too.)

The current text of the SAM mentions: "If the scope of a topic characteristic 
assignment is the empty set the statement is considered to have unlimited 
validity, and it is said to be in the unconstrained scope." I remarked that 
this should be the universal set rather than the empty set. (Or rather, since 
scopes consist of topics, it should be the set of all topics.) Lars agreed that 
this was an issue but was concerned about the repercussions for applications. 
When an iteration over the elements of a scope is defined, this would imply an 
interation over the universal set, which is not desirable.

The current positions on what the unconstrained scope is are:
- ISO 13250: all the topics in the entire topic map  ("This International 
Standard does not require that scopes be specified explicitly. If the scope of 
a topic characteristic assignment is not explicitly specified via one or more 
scope attributes, the scope within which the topic characteristic applies to 
the topic includes all the topics in the entire topic map; this special scope 
is called the unconstrained scope.")
- XTM: does not say anything about which set the unconstrained scope 
represents. ("Every characteristic has a scope, which may be specified either 
explicitly, as a set of topics, or implicitly, in which case it is known as the 
unconstrained scope. Assignments made in the unconstrained scope are always 
valid.")
- PMTM4: The scope comprised of the null set of topics -- the "no-topic" scope
- DRM: nothing, scope is for the SAM
- SAM: the empty set, see above

The ISO 13250 defintion is strange, since the unconstrained scope here is 
defined to be equivalent to the scope made up of all topics in the Topic Map. 
I.e. when we have a topic map which consists of two topics:

<topicmap>
  <topic id="NL">
    <topname>
      <basename>Netherlands</basename>
    </topname>
  </topic>
  <topic id="MdG">
    <topname>
      <basename>Marc de Graauw</basename>
    </topname>
  </topic>
</topicmap>

then ISO 13250 would imply that this is equivalent to:

<topicmap>
  <topic id="MdG">
    <topname scope="MdG NL">
      <basename>Marc de Graauw</basename>
    </topname>
  </topic>
  <topic id="NL">
    <topname>
      <basename>Netherlands</basename>
    </topname>
  </topic>
</topicmap>

Since both Topic Maps will behave differently when merging with a third one, I 
do not see how this could be correct. It is also strange to use a topic to 
scope it's own name as a general principle, although this would be correct in 
some circumstances. Further, the second Topic Map would seem to suggest that  
 the basename "Marc de Graauw" is not valid outside the defined scope (or not 
known to be valid), while the first Topic Map would seem to suggest that there 
is no known limitation to the validity of the basename "Marc de Graauw". Though 
strictly speaking this interpretation is up to applications, it still seems 
counterintuitive.

The reason it is undesirable for the unconstrained scope to be the empty set is 
that applications may very well decide to ask questions such as "is that scope 
a subset of this set of topics?". Since scopes are sets, such questions are 
natural. If the unconstrained scope is the empty set, no scope would be a  the 
subset of the unconstrained scope when it would be more natural to expect every 
defined scope to be a subset of the unconstrained scope. One can expect a lot 
of applications to use scope in such a way that a topic characteristic 
assignment in scope {a, b} is valid to a wider extent than an assignment in 
scope {b}. Since assignments in the unconstrained scope are always valid, it 
would seem more natural to define the unconstrained scope as {a, b, ... all 
other topics ... } then as {}.

There is, I think, a natural solution to the representation of the 
unconstrained scope. We must distinguish between explicitly defined scopes and 
implicitly defined scopes (XTM already does, and ISO 13250 speaks of explicitly 
and not-explicitly specified scopes). Then an explicitly defined scope is a 
scope element (in XTM) or attribute (in HyTM) or any corresponding data 
structure in an application with topics as elements (elements meant here in the 
mathematical sense, as elements of a set). An implicitly defined scope is one 
required by the processing of a Topic Map syntax, i.e. the unconstrained scope 
when no scope is explicitly defined. Then we could say that iteration is 
allowed over explicitly defined scopes, and not over implicitly defined scopes.

If that route is chosen, then there are several possibilities on the unconst  
rained scope:
1. It is the empty set, which is undesirable IMHO. In short, it forces 
applications to implement behaviour which is at odds with what the standard 
says.
2. It is the set of all topics. Any topic is an element of the unconstrained 
scope, and any set of topics is a subset of the unconstrained scope (though not 
necessarily a proper subset). The elements of explicitly defined scopes are 
accessible by applications, the elements of implicitly defined scopes (the 
uncontrained scope) are not.
3. Say nothing about the 'settiness' of the unconstrained scope. Explicitly 
defined scopes are sets of topics, what implicitly defined scopes (and thus the 
unconstrained scope) are is up to applications. The only thing that matters 
about the unconstrained scope is the consequences it has on merging.
4. The unconstrained scope is the set of all topics that are 'known' to be 
relevant for a Topic Map to an application. These would include:
- all topics in the Topic Map under scrutiny
- all topics in Topic Maps that are to be merged, either through <mergeMap> 
elements (in XTM) or through user-driven or application-driven merging.
This is an adaptation of ISO13250 which removes the undesired effects described 
above, but retains the idea. An advantage is that the unconstrained scope 
remains accessible, i.e. an iteration over the unconstrained scope is possible. 
It does not remove other peculiarities of the 13250 definition. The 
unconstrained scope will change when a topic is added to a Topic Map, and the 
unconstrained scope will be a different thing for different Topic Maps.

I think 2 would be the best route unless there are difficulties involved which 
I have overlooked.

Marc