Note on issues to be decided on scope

1 Introduction

This note discusses three related SAM issues:

1. prop-scope-structure,

2. term-scope-def, and

3. scope-unconstrained-rep.

The intention of the author is to give a survey of existing viewpoints, not to add new argumentation. This note will be input for the Montréal 2002 meeting of SC34WG3. Any new argumentation can be forwarded there by the attendees, or before that meeting on the mailing list by non-attendees. Such posted arguments should be read in conjunction with this note. Since I am off on holiday, I will not be able to change this note before Montréal. The attendees there can do so if they wish.

2 Issue 'prop-scope-structure'

See tm-standards.xtm.

Several people have signalled the need for a more structured scope. Three discussions merit special attention:

• Towards a general theory of scope, Steve Pepper & Geir Ove Grønmo.

• Bernard Vatant's proposals 1, 2, and 3.

• Kal Ahmed's proposal.

None of these are ready to be accepted as a definitive proposal yet.

And of course a position on the issue is we should not pursue a more structured scope but leave this up to applications.

Questions the meeting can decide on:

• Is a more structured scope to be pursued?

• If so, how will this take place? As part of the SAM effort, as part of a TMCL effort, or as a separate effort.

3 Issue 'term-scope-def'

See tm-standards.xtm.

This issue falls apart in several smaller and/or new ones.

  [economy = "economie" / dutch]

4 Issue 'scope-unconstrained-rep'

See: .

There is a problem with the ISO definition of scope.

Explanation: The ISO 13250 definition 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 these two 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 its 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.

There are a few alternatives for the unconstrained scope:

1. It is the empty set. (Only in 'all subjects' view.)

2. It is the set of all topics. (Only in 'any subjects' view.)

3. Leave it undefined.

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.

5. The unconstrained scope is the union of all topics currently used as scopes.

Solution 2. has as a problem that the set of all topics cannot be iterated. This might cause problems with TMQL implementations. (Note that proposals for structured scope might re-introduce this problem.)

Solution 3. is possible if the merging process is well defined. This would probably mean that the nature of the unconstrained scope is decided implicitly, and it that case it is better to do it explicitly.

Solutions 4. and 5. are similar and look a lot like ISO 13250:2000. They do not seem to avoid the problem sketched above: merging behaviour is different after the unconstrained scope 'translated' to an explicitly given scope.