The Standard Application Model for Topic Maps

2.1 Constraints

The model defined in this international standard contains not only basic types and information item types with named properties, but also constraints on the allowed instances of the model. The purpose of these constraints is to disallow uses of the model that are obviously inconsistent. The constraints are not exhaustive, so a topic map may conform to these constraints and still be inconsistent.

This international standard requires topic map processors to be able to detect violations of the constraints marked as 'SAM constraints' on behalf of topic map application. This international standard does not concern itself with when or how this detection is done, nor with how violations are reported.

3.1 Locator items

An information resource is a resource that can be represented as a sequence of bytes, and thus could in theory be retrieved over a network. Topic maps can refer to information resources external to themselves in order to make statements about them. These information resources are not part of the topic map; they are only referenced from it.

A locator is a string that references one or more information resources. Locators are always expressed in some notation, which defines their formal syntax and interpretation. The definition of locator notations is outside the scope of this specification.

In instances of this model locator items represent locators. Locator items have the following properties:

1. [notation]: A non-empty string. The string is the name of the notation used by this locator. If the string is "URI" the notation is that described in [RFC2396]. If not, the two first characters of the string must be "X-"; all values that do not begin with "X-" are reserved.

   Issue (prop-notation-interp):

   Is it likely that the term "IRI" will replace "URI" in the foreseeable future? Does there need to be well-defined mechanism for adding new possible values for the [notation] property?

   Ed. Note:
   HyTime locators must also have a defined notation.

2. [reference]: A non-empty string. The string is the locator, whose interpretation and syntax is governed by the value of the [notation] property.

Locator information items are equal if they have the same values in their [notation] and [reference] properties.

3.2 Source locators

The source locators of a topic map construct is a set of locators that may be used to refer to the construct, whether from inside or outside the topic map. When a topic map information set is created through deserialization from some topic map syntax source locators are created that point back to the syntactical constructs that gave rise to the information items in the information set. In these cases the source locators will point to the minimal syntactical construct of origin, which means that for topic items created from the XTM syntax, for example, the source locator will point to the originating topic element, rather than the containing topicMap element.

Information items may also have source locators assigned to them by means not constrained by this specification, in order that they may be referred to from outside (or within) the topic map.

Source locators are used in this specification to define reification, in the syntax specifications to ensure that when information is deserialized from different information resources cross references to topic map constructs are correctly interprete. Other parts of this international standard will use source locators to define mechanisms for referencing topic map constructs.

3.3 The topic map item

A topic map is a set of topics and associations, which may be represented in many forms. Its purpose is to convey information about subjects through the assignment of characteristics to topics representing those subjects. The topic map itself has no meaning or significance beyond its use as a container for the information about those subjects; in particular, the topic map does not represent anything but itself.

The topic map item may be reified, however, in order to make statements about the topic map, that is, the collection of topics and associations, as a whole. These statements may provide traditional metadata such as author, version, copyright, or they may reference system metadata such as a schema for the topic map, external documentation of it, and so on.

There is exactly one topic map item in each information set, and all information in the set is available from the properties of that item. Every topic map item represents a single topic map.

Topic map items have the following properties:

1. [source locators]: A set of locator items. This is the set containing the source locators of the topic map.

2. [topics]: A set of topic items. This is the set of all the topics in the topic map.

3. [associations]: A set of association items. This is the set of all the associations in the topic map.

4. [reifier]: A topic item, or null. The topic item is the topic that reifies this information item.

   The value of the property can be computed as follows: if there exists a topic item in whose [subject identifiers] property can be found a locator item equal to one in the [source locators] property of this information item that topic item is the value of this property. If not, the value is null.

   Issue (prop-reifier-computed):

   Is it acceptable for the [reified] property to be computed, or must it be a fundamental property?

   Issue (reifier-merging):

   What happens if two different topic items reify the same item? Should they be merged?

There is no defined procedure for comparing topic map items.

3.4 Topic items

A subject is anything that has identity. In the most generic sense, a subject is anything whatsoever, regardless of whether it exists or has any other specific characteristics, about which anything whatsoever may be asserted by any means whatsoever. In particular, it is anything on which the creator of a topic map chooses to discourse.

This international standard makes the following assumptions about subjects:

• Subjects are atomic, meaning that a subject is conceptually a single thing. That thing may be divisible into smaller components, but it is still a single thing. That is, to speak of two things is to speak of two subjects. To speak of a group consisting of two things is to speak of a single thing, which is the group—or possibly three: the group, and its two members.

• Subjects are identifiable, meaning that not only do subjects have identity, but their identity can also be established. Two mechanisms are provided for the purposes of establishing subject identity, one of which is formal, while the other is informal.

• Subjects are persistent, meaning that while a physical subject may disappear the subject still has identity in the sense that we may continue to speak of it. For example, while the halibut William Cowper ate is long gone [cowper], it is still possible to make statements about it, and therefore it is still a subject.

• Subjects are independent of perspective, meaning that while there may be different points of view on what something is each point of view is a subject in its own right. So while Plato speaks of 'the good' his notion of it is clearly a different subject from 'the good' of John Stuart Mill. For this reason topics have no scope; there is no limit to their validity as notions.

A topic is a symbol used within a topic map to represent some subject, about which the creator of the topic map wishes to make statements. Topics are proxies for the subjects they represent in order to allow statements to be made about the subjects through the assignment of characteristics to the topics that represent them.

Every topic represents one, and only one, subject. The process of merging ensures that whenever two topics are known to represent the same subject they are merged automatically. It may well be, however, that two topics may represent the same subject without this being detectable by the rules of this standard. The merging of topics is therefore disallowed only when it is clear that they must represent different subjects.

3.4.5 Properties

Topic items represent topics, and have the following properties:

1. [source locators]: A set of locator items. This is the set containing the source locators of the topic.

2. [base names]: A set of base name items. This is the set of base names assigned to this topic.

3. [occurrences]: A set of occurrence items. This is the set of occurrences assigned to this topic.

4. [roles played]: A set of association role items. This is the set of association roles played by this topic.

   The value of this property can be computed as follows: it is the set of all association role items whose [role playing topic] property contains this topic item.

5. [subject identifiers]: A set of locator items. The locator items refer to the subject indicators of this topic.

6. [subject address]: A locator information item, or null. The locator, if present, refers to the information resource that is the subject of this topic.

   Issue (prop-subj-address-values):

   Should this property only accept a single value?

   Issue (prop-subj-address-class):

   Are topics representing resources allowed as types?

   Issue (prop-subj-address-scope):

   Are topics representing resources allowed as themes in scopes?

   Issue (strings-as-subjects):

   Should it be possible to create topics that represent strings, and for it to be formally clear that these topics do represent particular strings? If so, how?

   Issue (merge-same-subj-ind-addr):

   Is it allowed for a topic to have the same locator item both as subject identifier and as subject address? If it does, must not this mean that the topic has two subjects?

7. [reified]: an information item, or null. This is the information item that is reified by this topic item; that is, the topic map construct that is the subject of this topic.

   The value of this property can be computed as follows: if any information item has in its [source locators] property a locator item equal to one in the [subject identifiers] property of this topic item, that information item is the value of this property. If not, the value is null.

SAM Constraint: Single reified

The computation that produces the value of the [reified] property must yield a single information item, as topics are required to have only one subject.

Two topic items are equal if they, when present in the same information set, are required to be merged, according to the rules of 4.1 Merging topics. If not they are not equal.

Issue (prop-reifier-topic):

Should topic items have a [reifier] property? Should it be possible to reify topics? If so, how?

Ed. Note:
How do we tell information sets apart?

3.5 Base name items

A base name is a name or label for a subject, expressed as a string. That is, it is something that identifies the subject (though not necessarily uniquely) and can be used as a label for the subject in user interfaces. The notion of a base name corresponds closely to the common sense notion of a name. Suitable base names for people, countries, and organizations are their names, while base names for documents, musical works, and movies might be their titles. Base names may have variant names, which are alternative forms of the name that may be more appropriate in some context.

Base names always have a scope, which defines in what contexts the base name is an appropriate label for the subject. A subject may have any number of base names, and the only basis for choosing which base name(s) to use in any given situation is their scope.

Base name items represent base names, and have the following properties:

1. [source locators]: A set of locator items. This is the set containing the source locators of the base name.

2. [value]: A string. This string is the base name.

   Issue (prop-value):

   Is [label] a better name?

   Issue (prop-value-null):

   If it may not be null, why may it be empty?

3. [scope]: A set of topic items. This set is the scope that represents the validity of this base name as a label for the subject.

4. [variants]: A set of variant items. This set contains the variant names that are alternative forms of the base name.

5. [reifier]: A topic item, or null. The topic item is the topic that reifies this information item.

   The value of the property can be computed as follows: if there exists a topic item in whose [subject identifiers] property can be found a locator item equal to one in the [source locators] property of this information item that topic item is the value of this property. If not, the value is null.

Base name information items are equal if the values of their [value] and [scope] properties are equal.

3.6 Variant items

A variant name is an alternative form of a base name that may be more suitable in certain contexts than the base name itself. The scope of the variant name is the only basis for establishing what variant name is most suitable in any given situation. A variant name may be a string, but it may also be any other kind of information resource.

When choosing a label for a topic applications are expected to select the base name they consider most appropriate, and then evaluate which of the forms of that base name is best suited for display in that particular context, which may be the base name or one of its variants. This standard does not constrain the process by which this is done.

Section 5.3 Variant name scopes defines some published subjects that may be useful for scope variant names.

Variant items represent variant names, and have the following properties:

1. [source locators]: A set of locator items. This is the set containing the source locators of the variant name.

2. [value]: A string, which may be empty, or it may be null. The string, if set, is the variant name. If it is not null, the [resource] property must be null.

3. [resource]: A locator item, or null. The locator, if set, refers to the information resource that is the variant name. If it is not null, the [value] property must be null.

4. [scope]: A non-empty set of topic items. This set is the scope that describes in what context(s) the variant name may be preferred as a label for the topic.

   Issue (prop-variant-scope-superset):

   ISO 13250:2000 allows a display name to have a scope that is a subset of that of the corresponding base name. This apparent contradiction needs to be resolved.

5. [reifier]: A topic item, or null. The topic item is the topic that reifies this information item.

   The value of the property can be computed as follows: if there exists a topic item in whose [subject identifiers] property can be found a locator item equal to one in the [source locators] property of this information item that topic item is the value of this property. If not, the value is null.

Variant information items are equal if the values of their [value], [resource], and [scope] properties are equal.

3.7 Occurrence items

An occurrence is a relationship between an information resource and a subject. The precise nature of this relationship is described by the occurrence type, a subject which is attached to the occurrence. Occurrences are generally used to attach information resources to the subjects they are relevant to. Note that the occurrence is properly not the resource, but the relationship between it and the subject. The information resource may either be a string inside the topic map or an external information resource.

All occurrences have a scope, which defines the contexts in which the occurrence relationship between the information resource and the subject is valid.

An occurrence item represents an occurrence and can have the following properties:

1. [source locators]: A set of locator items. This is the set containing the source locators of the occurrence.

2. [value]: A string, which may be empty, or it may be null. The string, if set, is the information resource the occurrence connects with the subject. If it is not null, the [resource] property must be null.

3. [resource]: A locator item, or null. The locator, if set, is the information resource the occurrence connects with the subject. If it is not null, the [value] property must be null.

4. [scope]: A set of topic items. This set is the scope that describes in what context the occurrence relationship may be considered valid.

5. [occurrence type]: A topic item, or null. The topic item represents the subject that defines the nature of the occurrence relationship.

6. [reifier]: A topic item, or null. The topic item is the topic that reifies this information item.

   The value of the property can be computed as follows: if there exists a topic item in whose [subject identifiers] property can be found a locator item equal to one in the [source locators] property of this information item that topic item is the value of this property. If not, the value is null.

Occurrence information items are equal if the values of their [value], [resource], [scope], and [occurrence type] properties are equal.

3.8 Association items

An association is a relationship between one or more subjects. Associations have an association type, a subject which describes the nature of the relationship. The involvement of each subject in the relationship is called its association role.

All associations have a scope, which defines the context in which the statement represented by the association can be considered valid. The scope applies to the association roles as characteristics of the topics that play these roles, but all association roles in an association have the same scope, and so the scope is considered to apply to the association as a whole as well.

Association items represent associations, and may have the following properties:

1. [source locators]: A set of locator items. This is the set containing the source locators of the association.

2. [scope]: A set of topic items. This set is the scope that describes in what context the association may be considered valid.

3. [association type]: A topic item, or null. The topic item represents the association type of the association.

4. [roles]: A non-empty set of association role items. The association role items represent the association roles that make up this association.

5. [reifier]: A topic item, or null. The topic item is the topic that reifies this information item.

   The value of the property can be computed as follows: if there exists a topic item in whose [subject identifiers] property can be found a locator item equal to one in the [source locators] property of this information item that topic item is the value of this property. If not, the value is null.

Association items are equal if the values of their [scope], [association type], and [roles] properties are equal.

3.9 Association role items

An association role connects two pieces of information within an association: the subject participating in the association, known as the association role player, and the subject defining the nature of its participation, known as the association role type.

Ed. Note:(larsga)
Should we include examples to make this clear? Here, or under association?

Ed. Note:(larsga)
The UML should declare that there is an inverse of rolePlayingTopic, which is roles.

Association role items represent association roles, and may have the following properties:

1. [source locators]: A set of locator items. This is the set containing the source locators of the association role.

2. [role playing topic]: A topic item, or null. This is the topic item that represents the association role player.

3. [role type]: A topic item, or null. This is the topic item that represents the association role type.

4. [reifier]: A topic item, or null. The topic item is the topic that reifies this information item.

   The value of the property can be computed as follows: if there exists a topic item in whose [subject identifiers] property can be found a locator item equal to one in the [source locators] property of this information item that topic item is the value of this property. If not, the value is null.

Association role information items are equal if the values of their [role type] and [role player] properties are equal.

4.1 Merging topics

Whenever two different topic items have

• at least one equal locator item in their [subject identifiers] properties,

• at least one equal locator item in their [source locators] properties,

• an equal locator item in their [subject address] property, or

• an equal locator in the [subject identifiers] property of the one topic item and the [source locators] property of the other.

they must be merged.

Merging of topic items is done by the following procedure. The two topic items to be merged are known as A and B.

1. Create a new topic item C.

2. Replace A by C wherever it appears in one of the following properties of some information item: [topics], [scope], [occurrence type], [association type], [role playing topic], and [role type].

3. Repeat for B.

4. Set C's [source locators] property to the union of the values of A and B's [source locators] properties.

5. Set C's [subject identifiers] property to the union of the values of A and B's [subject identifiers] properties.

6. If A or B has a value for the [subject address] property, set this as the value of C's [subject address] property.

7. Set C's [base names] property to the union of the values of A and B's [base names] properties, merging equal base name items in C's [base names] property according to the rules of 4.2 Merging base names.

8. Set C's [occurrences] property to the union of the values of A and B's [occurrences] properties.

4.2 Merging base names

Base names are merged when the [base names] property of a topic item contains two equal base name items. The procedure for merging two base name items A and B is given below.

• Create a new base name item C.

• Set C's [source locators] value to the union of the value of the [source locators] properties of A and B.

• Set C's [value] value to the value of the [value] property of A or B. If merging was triggered by the rules of this specification A and B should have the same rule. If not, applications may choose either value.

• Set C's [scope] value to the value of the [scope] property of A or B. If merging was triggered by the rules of this specification A and B should have the same value. If not, applications may choose either value.

• Set C's [variant] value to the union of the [value] properties of A and B.

Once merging is complete, A and B may be removed from the set, and C added in their place.

4.3 Merging topic maps

Topic map merging is an operation that given two separate topic maps produces a single topic map which contains all the statements made by the two source topic maps. This specification is not concerned with when topic map merging occurs, but specifies a minimal procedure for merging topic maps. Topic map processors are free to make additional merges based on extra information available to them.

The procedure of merging two topic maps uses two topic maps, a master topic map (A) and a subordinate topic map (B). All information items in B are merged into A, and A contains the information from both topic maps after the merge is complete.

1. Set the [topics] property of B to the union of the [topics] properties of A and B.

2. Set the [associations] property of B to the union of the [associations] properties of A and B.

3. Apply merging to the [topics] property of B until no duplicates remain.

4. Apply merging to the [associations] property of B until no duplicates remain.

4.4 Merging variant items

Two variant items, A and B, may be merged by following the procedure below.

1. Create a new variant item, C.

2. Set C's [source locators] property to the union of the values of A's and B's [source locators] properties.

3. Set C's [value], [resource], and [scope] properties to the value of A's [value], [resource], and [scope] properties, respectively. B's values are equal to those of A, and need therefore not be taken into account.

Once merging is complete, A and B may be removed from the set, and C added in their place.

4.5 Merging occurrence items

Two occurrence items, A and B, may be merged by following the procedure below.

1. Create a new occurrence item, C.

2. Set C's [source locators] property to the union of the values of A's and B's [source locators] properties.

3. Set C's [value], [resource], [scope], and [occurrence type] properties to the value of A's [value], [resource], [scope], and [occurrence type] properties, respectively. B's values are equal to those of A, and need therefore not be taken into account.

Once merging is complete, A and B may be removed from the set, and C added in their place.

4.6 Merging association items

Two association items, A and B, may be merged by following the procedure below.

1. Create a new association item, C.

2. Set C's [source locators] property to the union of the values of A's and B's [source locators] properties.

3. Set C's [scope], [roles], and [association type] properties to the value of A's [scope], [roles], and [association type] properties, respectively. B's values are equal to those of A, and need therefore not be taken into account.

Once merging is complete, A and B may be removed from the set, and C added in their place.

4.7 Merging association role items

Two association role items, A and B, may be merged by following the procedure below.

1. Create a new association role item, C.

2. Set C's [source locators] property to the union of the values of A's and B's [source locators] properties.

3. Set C's [role type] and [role playing topic] properties to the value of A's [role type] and [role playing topic] properties, respectively. B's values are equal to those of A, and need therefore not be taken into account.

Once merging is complete, A and B may be removed from the set, and C added in their place.

4.8 Merging locator items

Locator items are not merged. If two equal locator items appear in a set, their property values must be identical, and one can therefore be removed as redundant.

5.1 The type-instance relationship

A type is a set of individual subjects, each of which is an instance of the type. Types are generally used to represent sets of subjects which share some commonality, but this specification does not restrict the possible uses of types, or their meanings. A type may itself be an instance of another type, and there is no limit to the number of types a subject may be an instance of. Scope applies to this association type in just the same way as it does to any other.

The type-instance relationship is not transitive. That is, if A is a type of which B is an instance, and B is a type of which C is an instance, it does not follow that C is an instance of A.

The type-instance relationship between two topic items can be asserted in topic maps using an association item that conforms to the following rules:

• The [association type] property must be set to a topic item that has in its [subject identifiers] property a locator item with [notation] set to "URI" and [reference] set to "http://www.topicmaps.org/xtm/1.0/core.xtm#class-instance".

• The [roles] property must contain exactly two association role items.

• One of the association items in the [roles] property must have its [role type] property set to a topic whose [subject identifiers] property is set to a locator item with [notation] set to "URI" and [reference] set to "http://www.topicmaps.org/xtm/1.0/core.xtm#class". The [role player] property will then contain the topic item representing the type.

• One of the association items in the [roles] property must have its [role type] property set to a topic whose [subject identifiers] property is set to a locator item with [notation] set to "URI" and [reference] set to "http://www.topicmaps.org/xtm/1.0/core.xtm#instance". The [role player] property will then contain the topic item representing the instance.

Associations that use one or more of the published subjects defined in this section, but which do not conform to these structural rules, are not considered to represent type-instance relationships. Their interpretation is not defined by this international standard.

This specification does not require implementations to actually represent the type-instance relationship using associations, as long as they conform to the rules of this specification.

5.2 The supertype-subtype relationship

A type may be a subtype of another, which is then considered the supertype of the other. If B is the subtype of A, it follows that every instance of B is also an instance of A. The opposite it not necessarily true. The relationship between a supertype and its subtypes is known as the supertype-subtype relationship. A type may have any number of subtypes and supertypes. Scope applies to this association type in just the same way as it does to any other.

The supertype-subtype relationship is transitive, which means that if B is a subtype of A, and C a subtype of B, C is also a subtype of A.

The supertype-subtype relationship between two types can be asserted in topic maps using an association item that conforms to the following rules:

• The [association type] property must be set to a topic item that has in its [subject identifiers] property a locator item with [notation] set to "URI" and [reference] set to "http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass".

• The [roles] property must contain exactly two association role items.

• One of the association items in the [roles] property must have its [role type] property set to a topic whose [subject identifiers] property is set to a locator item with [notation] set to "URI" and [reference] set to "http://www.topicmaps.org/xtm/1.0/core.xtm#superclass". The [role player] property will then contain the topic item representing the supertype.

• One of the association items in the [roles] property must have its [role type] property set to a topic whose [subject identifiers] property is set to a locator item with [notation] set to "URI" and [reference] set to "http://www.topicmaps.org/xtm/1.0/core.xtm#subclass". The [role player] property will then contain the topic item representing the subtype.

Associations that use one or more of the published subjects defined in this section, but which do not conform to these structural rules, are not considered to represent supertype-subtype relationships. Their interpretation is not defined by this international standard.

5.3 Variant name scopes

The subject identifier http://www.topicmaps.org/xtm/1.0/core.xtm#sort (notation "URI"), identifies the notion of suitability of a variant name for use as a sort key for a subject. A variant item that has a topic with this subject identifier in its [scope] property represents a variant name intended to be used as a sort key for the topic item it belongs to.

The subject identifier http://www.topicmaps.org/xtm/1.0/core.xtm#display (notation "URI"), identifies the notion of suitability of a variant name for use as a display name for a subject. A variant item that has a topic with this subject identifier in its [scope] property represents a variant name intended to be used as a label for the topic item it belongs to. This published subject is included only for backwards compatibility with ISO 13250:2000.