A Proposal for Extending Scope in XTM

1. Introduction

This document outlines a proposal for an more prescriptive treatment of the concepts of scope and what it means for a characteristic assignment to be valid. The document goes on to propose the means by which this approach to scope might be encoded in an XML document.

2. Approach Principles

A number of observations about the nature of scope and the way in which practitioners tend to apply scope have lead to the development of this proposal. This section details some of those observations.

2.1 Topics defining the context may play different roles in that definition

To avoid ambiguity in the specification of a scope, each of the topics which define the scope should also specify a role in the scope. For example, an occurrence scoped by a topic representing a date might be an occurrence which should be restricted to being viewed only after the date specified; or it may used to restrict the resource to being viewed only up to the date specified. The date topic by itself cannot convey sufficient information to be of any use to a user agent. However, if a scope definition allowed each topc in the scope to specify its role, then the a role such as "display-date-start" or "display-date-end" could be use used to distinguish these two potential uses.

2.2 A single characteristic assignment may be valid in many different contexts

For example, a URL may specify a resource which provides a native language document based on the language headers sent by the HTTP user agent. Thus, an occurrence using such a URL may be valid both in the context of "French" and "English" simultaneously. It should therefore be possible to declare more than one context of validity for any given scope.

2.3 A single processing model based on set theory is not always sufficient.

Returning to our example of a resource which should be viewed only before/after a specified date. The scope definition itself should not be expected to contain a topic for each possible time in the interval; however a user agent with sufficient knowledge of the vocabulary being used for specifying topic roles in the scope could process the "display-date-start" and "display-date-end" roles and determine a match for these if the current date falls between the two.

3. Approach

3.1 Scope definition

A scope is defined using one or more contexts of validity. Each context of validity consists of one or more themes. The themes in a context of validity may optionally play a role in that context of validity. Each theme in a context of validity is defined by a topic. The role played by a theme in a context of validity is defined by a topic.

3.2 User context definition

A user agent may have one or more user contexts. A user context consists of one or more themes. The themes in a user context may optionally play a role in that user context. Each theme in a user context is defined by a topic. The role played by a theme in a user context is defined by a topic.

3.3 Determining validity

A user agent will determine that a characteristic assignment is valid if at least one context of validity in the scope of the characteristic assignment matches one user context.

3.3.1 Matching context of validity and user context

The basic rules for matching a context of validity and a user context are as follows:

1. For each theme playing a defined role in the context of validity, the same theme must also be found in the user context playing the same role or playing an undefined role.
2. For each them in the context of validity playing an undefined role, the same theme must also be found in the user context playing any role (including the undefined role).

Note: In the above rules themes are considered to be "the same" if they represent the same subject.

In addition to these basic rules, a user agent is free to determine a match by applying any other matching criteria to any theme playing a defined role in the context of validity or user context.

4. Representation in XTM.

4.1 Representing a context of validity in XTM

A single context of validity can be represented using an association. This association should be typed by a topic with a fixed subject indicator (e.g. http://psi.techquila.com/xtm/context-of-validity). The characteristic being scoped must play the role of "characteristic assignment", again specifid by a fixed subject indicator (e.g. http://psi.techquila.com/xtm/scoped-assignment). There must be at least one player of the "characteristic assignment" role in such an association. The themes in the scope are specified by the other role players in the association. The role specification for each player defines the role of the theme in the scope. A player with no specified role (i.e. one which defaults to the XTM "role" type) will be treated as a theme with no defined role in the scope.

4.2 Mapping of XTM 1.0 <scope> element

A scope element will be considered a shortcut to defining an association of type http://psi.techquila.com/xtm/context-of-validity, in which the role of type http://psi.techquila.com/xtm/scoped-assignment is played by a topic reifying the parent element of the <scope> element and in which each theme specified as a child of the <scope> element plays an undefined role.

Syntax Note: It is not necessary to create a <topic> element to reify a characteristic assignment. We can instead refer to the address of the element which makes the characteristic assignment with a subjectIndicatorRef.

4.3 An example in XTM syntax

<topicMap>

  <topic id="topic">
    <baseName id="bn">
      <baseNameString>Tennis</baseNameString>
    </baseName>
    <occurrence id="occ">
      <resourceRef xlink:href="www.tennis.nl"/>
    </occurrence>
  </topic>

  <!-- Tennis is a name valid for English -->
  <association>
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://psi.techquila.com/xtm/context-of-validity"/>
    </instanceOf>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://psi.techquila.com/xtm/scoped-assignment"/>
      </roleSpec>
      <subjectIndicatorRef xlink:href="#bn"/>
    </member>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://psi.techquila.com/theme-roles/valid-for-language"/>
      </roleSpec>
      <topicRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>
    </member>
  </association>

  <!-- Tennis is a name valid for Dutch -->
  <association> 
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://psi.techquila.com/xtm/context-of-validity"/>
    </instanceOf>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://psi.techquila.com/xtm/scoped-assignment"/>
      </roleSpec>
      <subjectIndicatorRef xlink:href="#bn"/>
    </member>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://psi.techquila.com/theme-roles/valid-for-language"/>
      </roleSpec>
      <topicRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#nl"/>
    </member>
  </association>

  <!-- The tennis.nl website requires knowledge of both Dutch and English to be intelligble -->	 
  <association>
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://psi.techquila.com/xtm/context-of-validity"/>
    </instanceOf>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://psi.techquila.com/xtm/scoped-assignment"/>
      </roleSpec>
      <subjectIndicatorRef xlink:href="#occ"/>
    </member>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://psi.techquila.com/theme-roles/valid-for-language"/>
      </roleSpec>
      <topicRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>
      <topicRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#nl"/>
    </member>
  </association>

</topicMap>
        

In the above example, if the user context included the themes for English and Dutch playing either no role at all or playing the role http://psi.techquila.com/theme-roles/valid-for-language, then both the name and the occurrence would be considered to be valid characteristic assignments for the topic 'tennis'. If one of the themes was in the context but not the other, then only the basename would be considered a valid characteristic assignment. If neither theme were in the user context, then the topic as it is specified here would have no valid characteristic assignments.

5. Change Log

04/07/2002

Removed glossary. Definitions are moved into the description of the approach.

03/07/2002

Initial version.

Previous: Developing A Topic Map Programming Model

Next: Topic Map Design Patterns For Information Architecture