ISO/IEC JTC 1/SC 34N0554

ISO/IEC JTC 1/SC 34

Information Technology --
Document Description and Processing Languages

Table of Contents

Topic maps are sets of subject proxies, each of which is a surrogate for a single subject. In the language of ISO 13250:2002, the general notion of subject proxies was divided into "topics," "associations," and "occurrences," despite all three being surrogates for subjects in any given topic map. The Topic Maps Reference Model (TMRM) concerns itself with surrogates for all kinds of subjects, including but not limited to subjects that fall strictly into one of the three traditional categories; it defines the notion of "subject proxy".

The TMRM also specifies requirements for disclosing how to determine whether two or more subject proxies are proxies for the same subject, and how to view all of them as a single proxy. In a topic map, if a subject proxy is the only proxy for its subject, then users can access all information about that subject through that proxy's single (virtual) "location".

Topic maps are useful ways of viewing information because, as in all kinds of maps (including geographic maps), every specific location is unique, and all information that is relevant to a given geographic location is available at the corresponding location in the map. For example, in a map of Russia that depicts cities and elevations, the elevation of St. Petersburg can be found at the place where St. Petersburg is depicted, but one would not expect to find this information at the place where Moscow is depicted. The idea of a unique location within the framework of a geographic map corresponds to the use of "subject proxy" within the TMRM.

All maps are written within specific frameworks of expression. In the case of geographic maps, the nature of the correspondence between locations on the map and actual geographic locations is determined by the framework within which the map is expressed. Often a projection technique, such as the Mercator projection technique, is an important aspect of the frameworks of geographic maps. Other aspects of framework design include decisions about what to depict and what not to depict, the symbols that will be used, and so on; the framework of a map can have many aspects and dimensions. No map can be understood in the absence of at least some understanding of its framework of expression. When people share the same understanding of the framework of a given map, they can understand that map in the same way.

Any map, regardless of its framework, can be seen in terms of any other mapping framework, but only if both frameworks are understood. Maps can be combined ("merged") if their frameworks are known, and if their contents can be understood in terms of a framework capable of encompassing the combination of their contents.

In the TMRM, the framework of expression of a topic map is called a "Topic Map Application (TMA)". The TMRM requires TMA disclosures to disclose, among other things:

1. the definitions of the kinds of properties ("property classes") that subject proxies can have,

2. the rules for determining when multiple proxies are surrogates for the same subject, and

3. the rules for merging the values of the properties of proxies, when it has been determined that the proxies are surrogates for the same subject and they need to be viewable as a single proxy.

The TMRM's disclosure requirements are designed to facilitate the uniform understanding and merging of diverse topic maps, so that all of the diverse, independently expressed information about each subject can be viewed as if it were available at that subject's unique virtual "location" -- its unique subject proxy.

This International Standard specifies:

1. The abstract definition of subject proxy.

2. The abstract definition of merging subject proxies.

3. The abstract definition of Topic Map Application (TMA), and requirements to be met by disclosures of TMAs.

4. Other definitions and specifications in support of the above.

This International Standard does not specify:

1. The subjects of subject proxies nor constraints on such subjects.

2. The classes of the properties of subject proxies nor constraints on such classes.

3. The values of the properties of subject proxies nor constraints on such values.

4. The supporting algorithms and data models that may be used to represent subjects, to detect when two or more subject proxies are proxies for the same subject, or to merge the values of Subject Identity Properties or Other Properties.

(Said of the value of a property of a subject proxy:) Unsupported by a disclosed conferral rule; given; axiomatic. The opposite of conferred (the values of properties of subject proxies can be either built-in or conferred).

(Said of the value of a property of a subject proxy:) Existing because of the operation of a conferral rule that is defined by the Topic Map Application (TMA) that defines the class of the property. The opposite of built-in (the values of properties of subject proxies can be either built-in or conferred).

Information that, either within itself and/or by reference to other information, comprehensively defines (or is part of a comprehensive definition of) a Topic Map Application (TMA). Optionally, a disclosure may also define one or more interchange syntaxes, data models, implementations, and/or implementation strategies, along with unambiguous and comprehensive instructions as to how instances of each such syntax, data model, etc. are intended to be interpreted in terms of the defined Topic Map Application.

The process whereby two subject proxies that are surrogates for the same subject become viewable as a single resulting subject proxy. The single proxy that results from such a merger has instances of all of the property classes of which either or both of the original two proxies have instances. If an instance of a given property class appears in only one of the original two proxies, then that property instance appears unchanged in the resulting single proxy. If both of the original subject proxies have instances of a given property class, the values of those instances are combined in conformance with the rule for combining the values of instances of that class that is disclosed by the TMA that governs the class, and the resulting value becomes the value of the instance of that property class that appears in the resulting single proxy.

A property class or property instance that is not a Subject Identity Property (SIP).

A named type of Subject Identity Property (SIP) or Other Property (OP), instances of which may appear in subject proxies. Within a TMA, the names of all property classes are unique.

One of the named values that comprise a subject proxy: an instance of a Subject Identity Property (SIP) or Other Property (OP). Its name is the same as the name of the property class of which it is an instance. In the subject proxy in which it appears, it is the only instance of its class.

The representation of a subject by a subject proxy.

Any thing whatsoever, regardless of whether it exists or has any other specific characteristics, about which anything whatsoever may be asserted by any means whatsoever. A potential or actual subject of conversation.

1. A property class whose instances specify the subjects of the subject proxies in which they appear.

2. A property instance that specifies the subject of the subject proxy in which it appears.

A surrogate for a subject. Subject proxies consist of property instances, at least one of which must be a Subject Identity Property (SIP). In a subject proxy, there cannot be more than one SIP whose class is defined by the same Topic Map Application (TMA).

1. A set of subject proxies that is treated as a unit. The classes of the properties (both SIPs and OPs) that comprise the subject proxies, and the rules for recognizing when multiple proxies are surrogates for the same subject, are both disclosed by one or more TMAs (called the "governing TMAs"). The governing TMAs also disclose the rules for viewing the values of multiple instances of each property class as a single value of that class; these rules enable multiple proxies for the same subject to be viewed as if they were a single proxy with a single instance of each property class.

2. An document written in a topic map syntax; an interchangeable expression of a set of subject proxies.

A Disclosure of rules that govern properties of subject proxies.

A subject-oriented view of a corpus of information, via a set of subject proxies that are governed by a TMA. By conforming to the TMA's rules for recognizing subject sameness, for merging the properties of proxies, etc., a topic map view can provide the convenience of subject-oriented access to the contents of the corpus.

This International Standard.

In a topic map view, all subjects for which a single virtual "location" can be established have a surrogate, that is, a subject proxy. Every subject proxy is a surrogate for a single unique subject.

The constraint that every subject proxy must have, among its properties, one SIP per governing TMA, fulfills two related but independent functions:

1. the SIP instances collectively identify the subjects that the author of a particular topic map view chose to reify; and

2. the classes of the SIP instances reveal how the author chose to distinguish those subjects from one another, or, in other words, how the author chose to recognize when two or more proxies have the same subject.

The function of SIP instances (that is, specifying the subjects of the subject proxies created by an author) enables interchange of topic map views with the expectation that the view as authored can be the same view seen by a user. The user is not constrained to take that view, but, since the ability to interchange topic map views is a requirement, this International Standard must enable authors to give users of topic map views the ability to replicate the views as authored.

The function of SIP classes (that is, revealing how the topic map view's author chose to distinguish the subjects of subject proxies) facilitates the merging of independently authored topic map views, not only when the views are expressed in terms defined by the same TMAs, but also when the TMAs are different. In the latter case, each independent TMA's Disclosure of its means for distinguishing the subjects of subject proxies can provide a useful basis for designing rules for combining the proxies governed by the independent TMAs.

Each Disclosure of a Topic Map Application (TMA) must disclose the following things:

1. Topic Map Application Name. The name of the TMA.

2. Property Class Names. The names of all of the TMA's Subject Identity Property (SIP) and Other Property (OP) classes. Every TMA must define at least one SIP class, but OP classes are optional. Within a given TMA, the names of all SIP and OP classes must be unique; they all share the same namespace.

3. Property Value Constraints. Definitions of the constraints on the values of instances of each SIP class and OP class. These constraints may include, for example, their value types.

4. Property Instance Merging Rules. For each SIP class and OP class, a definition of the rule for combining the values of multiple instances of it into the value of a single instance.

   Note 5:  Whenever two subject proxies have been determined to have the same subject and each of them has an instance of a given property class, the values of the two property instances are combined into the value of a single instance of the same property class. (Each subject proxy has only one instance of each property class.) TMA-defined property instance merging rules disclose how that calculation should be made for all of the instances of each property class.

   
   

   Note 6:  When combining two or more subject proxies, if there is a single instance of a property, then that instance is preserved in the merged subject proxy. (See the definition of merging.)

   
   

   Note 7:  Designers of TMAs are free to define rules for combining the values of multiple instances of property classes in such a way that they must raise exceptions or have other special behaviors when combining the values is impossible, or when combining them would violate the logic of the TMA. Such exceptional behaviors are unconstrained by the TMRM; they are left to the discretion of TMA designers.

   
   

5. Subject Sameness Detection Rules. For each SIP class, the rule for comparing any two instances of the class in order to determine whether they specify the same subject, i.e., whether the subject proxies in which two instances of the same SIP class appear can be viewed as a single subject proxy in which their respective property instances have been merged.

6. Conferral Rules. If the TMA includes rules (called "conferral rules") that require values or value components to be conferred upon property instances, then, for each conferral rule, the property/value conditions that trigger the operation of the rule, and the effects of its operation on property values, must be disclosed. Conferral rules can require the conferral of values or value components on property instances that do not have any built-in value components, and therefore would not exist without their conferred values; such property instances are said to be "conferred into existence". Property instances that are conferred into existence may appear in subject proxies that would not otherwise have any property instances, and therefore would not otherwise exist; such subject proxies are also said to be "conferred into existence".

   Note 8:  Individual topic maps may or may not have any proxies whose property values are conferred (as opposed to built-in). For example, a topic map can be governed by a TMA that has no conferral rules, or that has conferral rules whose triggering conditions are unmet in the topic map. However, every a topic map must have at least one built-in property value; without it, there would be nothing to trigger the operation of any conferral rule.

   
   

The following grammatical productions are expressed in a notation similar to that of Clause 5 of ISO 8879. They summarize what the TMRM requires TMA Disclosures to disclose, and how the property instances that appear in the subject proxies of topic map views invoke the disclosures that apply to them by means of the names of TMAs, SIP classes, and OP classes.

(1) topicMapApplicationDisclosure = (topicMapApplicationName, propertyClassDefinition+, conferralRuleDefinition*)

(2) propertyClassDefinition = ( SIPClassDefinition | OPClassDefinition)

(3) SIPClassDefinition = (propertyClassName propertyValueConstraints, propertyInstanceMergingRule, propertyInstanceSubjectSamenessDetectionRule)

(3) OPClassDefinition = (propertyClassName propertyValueConstraints, propertyInstanceMergingRule)

(4) subjectProxy = (SIPInstance+, OPInstance* )

(5) (SIPInstance | OPInstance) = (topicMapApplicationName, propertyClassName, propertyValue)

(6) (topicMapApplicationName | propertyClassName | propertyValueConstraints | propertyInstanceMergingRule | propertyInstanceSubjectSamenessDetectionRule | propertyValue) = [unconstrained by the TMRM]

(7) conferralRule = [unconstrained by the TMRM, except that only instances of property classes defined by the same TMA that defines the conferral rule can have values conferred upon them by that conferral rule.]

(8) topicMapView = (topicMapApplicationName+, subjectProxy+)

While extremely interesting as an implementation strategy or model, the Tau model has no concept of identity (by design), preferring to leave that issue to other parts of the topic maps standard.

For the TMRM, on the other hand, the question of identity lies at the core of having a topic map view. That is, in order to have interchangeable, mergeable, or even useful topic map views, one must know what was authored as a subject proxy (in TMRM terms, what possesses an SIP) and on what basis that SIP was to be compared to others for purposes of detecting subject sameness, and what to do when subject sameness is detected. Knowledge of how such processing will be performed is of vital interest to promote use of topic maps, but is not the same as formulation of a the requirements for disclosing those choices.