ISO/IEC 13250:2003

INTERNATIONAL ISO/IEC
STANDARD 13250
Second edition
2003-05-15
Information technology — SGML
applications — Topic maps
Technologies de l'information — Applications SGML — Plans relatifs à
des sujets
Reference number
©
ISO/IEC 2003
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall
not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the
unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2003
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
©
ii ISO/IEC 2003 – All rights reserved

Contents Page
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Notation . 6
5 Topic maps architecture . 7
6 Conformance . 24
Annex A (normative) Topic maps meta-DTD . 25
Annex B (informative) Example of an architectural support declaration for the topic maps
architecture . 38
Annex C (normative) XML DTD for web-oriented topic maps . 39
©
ISO/IEC 2003 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations, governmental and non-
governmental, in liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for
voting. Publication as an International Standard requires approval by at least 75 % of the national bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC13250 was prepared by Joint Technical Committee ISO/IEC JTC1, Information technology,
Subcommittee SC 34, Document description and processing languages.
This second edition cancels and replaces the first edition (ISO/IEC 13250:2000), which has been technically
revised.
©
iv ISO/IEC 2003 – All rights reserved

Introduction
This International Standard provides a standardized notation for interchangeably representing information
about the structure of information resources used to define topics, and the relationships between topics. A set
of one or more interrelated documents that employs the notation defined by this International Standard is called
a topic map. In general, the structural information conveyed by topic maps includes:
— groupings of addressable information objects around topics (“occurrences”), and
— relationships between topics (“associations”).
A topic map defines a multidimensional topic space — a space in which the locations are topics, and in which
the distances between topics are measurable in terms of the number of intervening topics which must be visited
in order to get from one topic to another, and the kinds of relationships that define the path from one topic to
another, if any, through the intervening topics, if any.
NOTE 1 Two topics may be connected through an association, and they can also be connected by virtue of sharing an
occurrence.
In addition, information objects can have properties, as well as values for those properties, assigned to them
externally. These properties are called facet types.
NOTE 2 The word facet can mean one side of a many-sided, polished object, or one segment of a compound eye (e.g. an
insect's). Its metaphorical use here captures the idea that a facet is a property of a set of information objects that can be
used to create a view of them.
Several topic maps can provide topical structure information about the same information resources. The topic
maps architecture is designed to facilitate merging topic maps without requiring the merged topic maps to be
copied or modified. Because of their extrinsic character, topic maps can be thought of as overlays on, or
extensions to, sets of information objects.
The base notation of topic maps is SGML; an interchangeable topic map always consists of at least one SGML
document, and it may include and/or refer to other kinds information resources. A set of information resources
that comprise a complete interchangeable topic map can be specified using the “bounded object set (BOS)”
facility defined by the HyTime architecture in ISO/IEC 10744:1997.
As the Extensible Markup Language (XML), a World Wide Web Consortium recommendation, is a subset of
SGML, as explained in Annex K of SGML (1997), also known as WebSGML, XML can be also used as a base
notation for Topic Maps.
The topic map notation is defined as an SGML Architecture, and this International Standard takes the form of an
architecture definition document expressed in conformance with Normative Annex A.3 of ISO/IEC 10744:1997,
the SGML Architectural Form Definition Requirements (AFDR). The formal definition of the topic map notation
is expressed as a meta-DTD.
©
ISO/IEC 2003 – All rights reserved v

.
vi
INTERNATIONAL STANDARD ISO/IEC 13250:2003(E)
Information technology — SGML applications — Topic maps
1Scope
NOTE 1 This clause defines the scope of this International Standard. It should not be confused with the concept of “scope”
defined in 3.16, which only applies in the context of topic maps.
Topic maps enable multiple, concurrent views of sets of information objects. The structural nature of these views
is unconstrained; they may reflect an object oriented approach, or they may be relational, hierarchical, ordered,
unordered, or any combination of the foregoing. Moreover, an unlimited number of topic maps may be overlaid
on a given set of information resources.
Topic maps can be used:
— to qualify the content and/or data contained in information objects as topics to enable navigational tools
such as indexes, cross-references, citation systems, or glossaries;
— to link topics together in such a way as to enable navigation between them. This capability can be used for
virtual document assembly, and for creating thesaurus-like interfaces to corpora, knowledge bases, etc.;
— to filter an information set to create views adapted to specific users or purposes. For example, such filtering
can aid in the management of multilingual documents, management of access modes depending on
security criteria, delivery of partial views depending on user profiles and/or knowledge domains, etc.;
— to structure unstructured information objects, or to facilitate the creation of topic-oriented user interfaces
that provide the effect of merging unstructured information bases with structured ones. The overlay
mechanism of topic maps can be considered as a kind of external markup mechanism, in the sense that an
arbitrary structure is imposed on the information without altering its original form.
This International Standard does not require or disallow the use of any scheme for addressing information
objects. Except for the requirement that topic map documents themselves be expressed using SGML (or
WebSGML) and HyTime, using the syntax described herein, neither does it require or disallow the use of any
notation used to express information.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced document
(including any amendments) applies.
ISO 8879:1986, Information processing — Text and office systems — Standard Generalized Markup Language
(SGML)
ISO/IEC 10744:1997, Information technology — Hypermedia/Time-based Structuring Language (HyTime)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 8879:1986, ISO/IEC 10744:1997 and
the following apply.
©
ISO/IEC 2003 – All rights reserved 1

3.1
added themes
topics added to the sets of themes comprising the scopes within which topics have their topic characteristics;
added themes can be specified in two ways:
a) within the topic map document whose scopes are affected, by means of the added themes (addthems)
attribute of the document element. The specified themes are added to the scopes of all of the topic
characteristics which are assigned to topics via the topic links and association links contained in the
document;
b) inside or outside the topic map document whose scopes are affected, by means of elements conforming to
the themes to be added (addthms) architectural form. The specified themes are added to the topic
characteristics assigned to topics via:
— entire topic map documents (specified via the tmdocs attribute),
— topic links (that is, the name characteristics and occurrence characteristics assigned to topics via topic
links) (specified via the cassign attribute),
— association links (that is, the roles played in associations by topics, as assigned to topics via association
links) (specified via the cassign attribute), or
— any combination of the foregoing
3.2
association
SEE topic association (3.22)
3.3
association link
hyperlink element conforming to the association link architectural form defined by this International Standard
NOTE See 5.4.
3.4
association role
one of the roles that topics play in a given topic association
3.5
association type
subject which is a class of topic associations
one of the classes of topic associations of which a particular association link is an instance; the association
types of which a given association link is an instance can be specified by its optional types attribute
3.6
base name
subelement (basename) of a topname subelement of a topic link
name characteristic of a topic that is specified in the content of a basename element
3.7
bounded object set
BOS
set of one or more documents and other information objects, all of which are known to the processing
application and which are processed collectively, see ISO/IEC 10744:1997 for details; see also the definition of
“hub document”
3.8
display name
subelement (dispname) of a topname subelement of a topic link, containing the identifying information intended
to be displayed by the application to represent the subject of the topic link
name characteristic of a topic that is specified in the content of a dispname element
©
2 ISO/IEC 2003 – All rights reserved

3.9
facet
subset of information objects that share an externally-applied property
values given to a particular property externally applied to a set of information objects
3.10
facet link
hyperlink that applies values for a given property (as well as the property itself) to one or more information
objects
3.11
facet type
property applied by one or more facet links to one or more objects
3.12
facet value
member of the set of all values of a particular facet type
3.13
hub document
HyTime document used to define the set of information resources (the bounded object set (BOS)) that comprise
a HyTime hyperdocument; applications may regard the HyTime document used as the entry point for a
browsing session within a hyperdocument as the hub document; see ISO/IEC 10744:1997 for details; by
definition, a topic map is a HyTime hyperdocument, and any topic map document can be regarded as a hub
document
3.14
occurrence role
sense in which some set of occurrences is relevant to a topic; in the topic maps architecture, occurrence roles
are specified as anchor roles (as defined in the HyTime architecture) of topic links
3.15
public subject descriptor
subject descriptor (see the definition of “subject descriptor”) which is used (or, especially, which is designed to
be used) as a common referent of the identity attributes of many topic links in many topic maps; the subject
described by the subject descriptor is thus easily recognized as the common binding point of all the topic links
that reference it, so that they will be merged
3.16
scope
extent of the validity of a topic characteristic assignment (see the definition of “topic characteristic assignment”):
the context in which a name or an occurrence is assigned to a given topic, and the context in which topics are
related through associations; 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”; if a scope is specified, the specification consists of a set of
topics, which, in the context of their role as members of such a set, are called “themes”; each theme contributes
to the extent of the scope that the themes collectively define; a given scope is the union of the subjects of the
set of themes used to specify that scope
NOTE 1 The definition of scope provided here should not be confused with 1, entitled “Scope”, which defines the Scope of
this International Standard.
NOTE 2 If it is desired to specify a scope which is the intersection (rather than the union) of two topics, this can be
accomplished by creating a topic whose subject is that intersection, and then by using that topic as a theme.
©
ISO/IEC 2003 – All rights reserved 3

3.17
sort name
subelement (sortname) of a topname subelement of a topic link, containing a string that is an alternative
representation of a topic name that is intended to be used for alphabetic or other ordering
name characteristic of a topic that is specified in the content of a sortname element
3.18
subject
in the most generic sense, a “subject” is 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
NOTE The invisible heart of every topic link is the subject that its author had in mind when it was created. In some sense,
a topic link reifies a subject. The identity attribute of a topic link is provided to allow the author of the topic link to indicate, as
unambiguously as possible, the subject he had in mind as the organizing principle of the topic. See the definition of “subject
descriptor”.
3.19
subject descriptor
information which is intended to provide a positive, unambiguous indication of the identity of a subject, and
which is the referent of an identity attribute of a topic link. (See also the definition of “public subject descriptor”.)
NOTE 1 There is no requirement that a subject descriptor be text, although it can be the text of a definition of the subject.
It can also, for example, be a listing in a catalog of subjects, such as an acquisition number of an asset in a museum
collection, a catalog number in a sales catalog, or a subject heading in a catalog of library subject headings. The distinction
between a subject descriptor that happens to be a definition and an ordinary occurrence of a definition is that, in the case of
the subject descriptor, the topic link's author has indicated (by referring to it by means of the value of the identity attribute)
that it is to be regarded as the authoritative definition of the organizing principle of the topic link. In the other case, by
characterizing a definition as a definitional occurrence, the author is merely acknowledging the existence of the definition
and its possible relevance to the subject of the topic link.
NOTE 2 Subject descriptors may be offline resources.
3.20
theme
member of the set of topics comprising a scope within which a topic characteristic assignment is valid. See also
the definitions of “scope” and “topic”
3.21
topic
aggregate of topic characteristics, including zero or more names, occurrences, and roles played in associations
with other topics, whose organizing principle is a single subject
topic link element
NOTE See 5.3.
3.22
topic association
specific relationship among specific topics that is asserted by an association link element
association link element
NOTE See 5.4.
3.23
topic characteristic
any defining characteristic of a topic; there are three kinds of topic characteristics:
©
4 ISO/IEC 2003 – All rights reserved

a) names,
b) occurrences, and
c) roles played in relationships (“associations”) with other topics
EXAMPLE A name of a topic is a “name characteristic” of that topic.
3.24
topic characteristic assignment
mechanism whereby a topic characteristic becomes a characteristic of a topic
EXAMPLE Topname subelements of topic link elements are used to assign names to topics as topic characteristics, so, in
topic map documents, they perform the function of assigning topic name characteristics.
fact that a particular topic characteristic is a characteristic of a particular topic
3.25
topic link
hyperlink element conforming to the topic link architectural form defined in 5.3 by this International Standard
NOTE 1 In this International Standard, the foregoing definition is invoked by the phrase “topic link”, or, since the default
SGML name of the topic link architectural form is “topic”, by the special typography used to distinguish SGML names (i.e.
topic).
NOTE 2 See also the definition of “topic”.
3.26
topic map
set of information resources regarded by a topic map application as a bounded object set whose hub document
is a topic map document conforming to the SGML architecture defined by this International Standard
topic map document conforming to the SGML architecture defined by this International Standard, or the
document element (topicmap) of such a document
document element type (topicmap) of the topic map document architecture
3.27
topic name
string of characters specified as a name of a topic; a name characteristic of a topic
topic name (topname) element, as defined by this International Standard
either a base name (basename), display name (dispname) or name to be used as sort key (sortname) element,
as defined by this International Standard, and/or the information that such an element contains
combination of the foregoing definitions
3.28
topic occurrence
information that is specified as relevant to a given subject
NOTE Topic occurrences may be offline resources.
3.29
topic type
subject which is a class of topics
one of the classes of topics of which a particular topic link is an instance; the topic types of which a given topic
link is an instance can be specified via its optional types attribute
©
ISO/IEC 2003 – All rights reserved 5

3.30
unconstrained scope
the scope comprised of all of the topics in a topic map; when no applicable scope attributes are explicitly
specified as governing a topic characteristic assignment, the scope within which the topic characteristic
assignment is made is the unconstrained scope
NOTE In other words, the unconstrained scope is the default scope. Thus, for example, in a given topic map, if no scope
attributes are explicitly specified for the name characteristics of any topics, any two topic links that have any of the same
names will be merged, due to the effect of the topic naming constraint.
4Notation
4.1 General
Topic Maps is an enabling document architecture whose definition (this International Standard) conforms to the
Architectural Form Definition Requirements in Normative AnnexA.3 of ISO/IEC10744:1997, the SGML
Architectural Form Definition Requirements (AFDR). The formal definition of the topic map notation is
expressed as a meta-DTD. The specification of the topic maps architecture is accomplished by a combination
of narrative text and formal definitions.
Any references in this document to industry and proprietary standards, products, user groups, and publications
are not normative, and do not imply endorsement by ISO, IEC, or their national member bodies or affiliates. Any
brand names or trademarks mentioned are the property of their respective owners.
The formal definitions are expressed in SGML.
The formal SGML definitions are part of the text of this International Standard and are protected by copyright.
In order to facilitate conformance to the topic maps architecture, the formal SGML definitions may be copied as
specified in the following copyright notice: Copyright (C) 2000 International Organization for Standardization.
Permission to copy in any form is granted for use with conforming Topic Maps systems and applications as
defined in ISO/IEC 13250:2003, provided this notice is included in all copies. The permission to copy does not
apply to any other material in this International Standard.
NOTE 1 This document uses editorial conventions mandated by the ISO with which the reader should be familiar in order
to understand the implications of certain words.
The text describing each construct emphasizes semantics, while the formal SGML definition provides the
rigorous syntactic definitions underlying the text descriptions.
NOTE 2 For this reason, it is recommended that the reader refer to the SGML definitions while reading the textual
descriptions. Although the SGML definition always follows the related text, the user may find it helpful to read the SGML first
in some cases. The meta-DTD is found in “Annex A (normative) Topic maps meta-DTD”.
When a construct is first introduced, it is described in the text. If the construct occurs in the formal SGML
specification, both the formal SGML name and a full name in English are presented, as follows:
— The element form full construct name (SGMLname) .
— The attribute full construct name (SGMLname) .
The declarations include comments, called “conventional comments”, that follow conventions established in the
HyTime standard to specify syntactic and semantic constraints and other information that is known to an
architecture engine such as a topic maps engine. The conventional comments do not extend SGML in any way.
They are used in the architecture definitions only, as a notation for the documentation of the architecture. They
need not be included in application DTDs and, if they are included, the SGML parser will treat them as it would
any other comment.
©
6 ISO/IEC 2003 – All rights reserved

4.2 RCS name, full name, description, and clause
Every form name is followed by comments giving the full name, a description of the form, and the number of the
clause in this International Standard in which the form is defined.
Individual attributes have a full name and description comment.
4.3 Constraints
Comments labeled “Constraints” define additional semantic or syntactic constraints on the constructs they
follow. Constraint comments that follow the name of a form define constraints on the use of that form in general.
Constraint comments that follow a component of a declaration (for example, the default value prescription of an
attribute declaration), define the specific constraints on that component.
4.4 Note
Note comments provide additional information not provided by the other comment types and are informational
rather than constraining.
5 Topic maps architecture
5.1 General
This clause defines the syntax of topic maps. The topic maps syntax makes use of the base, location address,
and hyperlinking modules of the HyTime architecture as defined in Clauses 6, 7 and 8 of ISO/IEC 10744:1997.
NOTE 1 The entire formal definition of the topic maps syntax, the topic maps meta-DTD, is found in normative Annex A of
this International Standard.
When interchanged, topic maps are HyTime bounded object sets (BOSs). The hub document of such a BOS
must contain a topic maps architectural support declaration (see Annex B for examples).
Only one of the hyperlink syntaxes defined by HyTime is used in the topic map syntax: variable link (varlink).
The HyTime architecture provides a comprehensive set of addressing mechanisms and a standard syntax for
using them. In addition, it provides means whereby any addressing syntax can be declared and used. The topic
map architecture preserves these features of HyTime. Thus, the topic maps architecture allows topic map
authors to use any addressing scheme, including proprietary addressing mechanisms driven by expressions in
any notations, provided each such notation is formally declared as a notation in the manner prescribed by the
SGML and HyTime International Standards.
NOTE 2 For example, in an XML environment, location addressing can be accomplished using IETF Uniform Resource
Locator (URL) notation.
5.2 Topic map architectural form
The topic map (topicmap) element form is used as the document element of all documents that conform to the
topic maps architecture defined by this International Standard.
The effect of specifying the added themes (addthems) attribute is to add the themes that it references to the
scopes of all of the topic characteristic assignments made throughout the document of which the element is the
root element.
NOTE 1 See the definition of “added themes”.
©
ISO/IEC 2003 – All rights reserved 7

NOTE 2 The addthems attribute can be used to acknowledge and document the fact that the document specifies only topic
characteristic assignments that are within the scope defined by the set of themes that it specifies. It can be used to avoid
specifying these common themes explicitly in every scope. After a topic map document is merged with other topic map
documents, the contributions that it made to the resulting merged topic map can be distinguished from the contributions of
all others by virtue of the fact that everything it contributed continues to appear within the scopes of the topics specified by
the addthems attribute of its document element.
The topicmap element type is derived from the document element type of the HyTime architecture (HyDoc). All
of the remaining attributes (maxbos, boslevel and grovplan) are inherited from HyDoc. The optional maxbos and
boslevel attributes are used in hub documents in specifying the members of the HyTime bounded object set
rooted at the document. The optional grovplan attribute is used in HyTime addressing. (See
ISO/IEC 10744:1997.)
NOTE 3 As the use of the TMCFC parameter entity indicates, valid topic map documents may or may not have any topic
links, association links or facet links in them. Some conforming applications may support only facet element types, while
others may not support facet element types.
TMCFC     -- Topic map context-free content --
"topic|assoc|facet|bosspec|addthms|TMBrid"
>
TMBrid    -- Topic map bridge element --
- O
ANY
>
topicmap    -- Topic map document element --
-- Clause: 5.1 --
- O
(%TMCFC;)*
>
topicmap
HyTime     -- HyTime architectural form name --
NAME
HyDoc    -- HyTime document element. (This
attribute definition is redundant; it
appears here as an aid to
understanding.) --
addthems    -- Added themes --
-- Themes to add to all scopes that govern
the assignments of topic names,
occurrences, and roles played in
associations in this topic map
document. --
CDATA    -- Reference --
-- Reftype: topic+ --
#IMPLIED  -- Default: No themes added via this
attribute. --
-- bos --   -- HyTime bounded object set --
-- HyTime Clause: 6.5.1 --
maxbos     -- Maximum bounded object set level --
-- Bounding level of HyTime bounded object
set when document is a hub or
subhub. --
NUMBER   -- Constraint: Depth of nested entities to
include in BOS (0=no limit, 1=hub only)
--
©
8 ISO/IEC 2003 – All rights reserved

boslevel    -- Bounded object set level --
-- Default BOS level used by data entities
declared in hub document. --
NUMBER   -- Constraint: Depth of nested entities to
include in BOS (0=no limit, 1=this
entity only) --
#IMPLIED  -- Default: No HyTime BOS --
-- bosspcat --  -- BOS exception specification attributes
--
-- HyTime Clause: 6.5.3 --
bosspec    -- Bounded object set exception
specification --
-- Adjustments to be made to the bounded
object set. --
IDREFS   -- Reference --
-- Reftype: bosspec+ --
-- Constraint: Must be internal reference
--
#IMPLIED  -- Default: No BOS exception specification
--
-- dgrvplan --  -- HyTime document grove plan --
-- HyTime Clause: 7.1.4.1 --
grovplan    -- Grove plan --
-- Grove plan for HyTime extended SGML
document grove --
CDATA    -- Reference --
-- Reftype: grovplan --
#IMPLIED  -- Default: HyTime default grove plan --
>
5.3 Topic link
5.3.1 Topic link architectural form
The topic link (topic) element form is used to assign topic name characteristics and topic occurrence
characteristics to a topic.
Every topic link is intended by its author to be organized around exactly one subject, regardless of whether that
subject is explicitly defined anywhere. A topic link may declare zero or more names and zero or more pieces of
information (“occurrences”) that are relevant to its subject. Names, and the scopes within which the names are
applicable to the subject, are declared by means of topname subelements. Occurrences are the anchors of the
topic link; these, and the scopes within which the occurrences are applicable to the subject, are specified by
means of occurs subelements.
The required unique identifier (id) attribute facilitates the addressing of topics by association links, by the
identity attributes of other topic links, and, in their roles as themes in scopes, by scope and addthems attributes.
The optional subject identity (identity) attribute refers to one or more indications (“subject descriptors”) of the
identity of the subject (the organizing principle) of the topic link. All of the other topic characteristics specified by
the topic link are regarded as elaborating, and in no way contradicting, the subject described by the subject
descriptor(s), if any. There are no restrictions on the kinds of information that may be referenced by an identity
attribute.
NOTE 1 The information referenced by an identity attribute may or may not take the form of a topic link in a topic map
document, may or may not be text, may or may not be machine-interpretable, and may or may not be online.
Any two or more topic links that reference the same subject by means of their identity attributes are equivalent
to a single topic link that has the union of the characteristics (the names, occurrences, and associations) of both
©
ISO/IEC 2003 – All rights reserved 9

topic links. The two or more topic links may be merged, and/or applications may process and/or render them as
if they have been merged.
NOTE 2 The two or more topic links do not have to refer to the same subject descriptor in order to be merged under this
rule. It is only necessary that the subject that is somehow indicated by the two identity attributes be one and the same
subject. If two or more topics refer to exactly the same subject descriptor, the subject descriptor may be described as a
“public subject descriptor”, and it becomes possible to automate the merging of all such topics by making the assumption
that, if they all share the same subject descriptor, they all share the same subject identity.
Similarly, if the identity attribute references one or more topic links, topic map processing applications must
regard the referencing topic link, and all the referenced topic links, as having one and the same subject, and
therefore they may all be merged.
The optional topic types (types) attribute references one or more topic links. The subject of each such
referenced topic link is a class of subject of which the subject of the referencing topic link is an instance. The
class-instance relationship established between the subject of each referenced topic link and the subject of the
referencing topic link could alternatively be established by a topic association link whose semantic is the
relationship between a class and an instance of that class.
NOTE 3 In other words, the types attribute establishes a relationship between topics (a topic association), rather than being
a means whereby the referencing topic becomes an occurrence of each of the referenced topics.
The topic relationships established by the types attribute are not superclass-subclass relationships. They are
only class-instance relationships.
NOTE 4 Superclass-subclass relationships between topics can be asserted by topic association links that have been user-
defined for that purpose.
The optional scope (scope) attribute references the themes that are added to the scopes within which all
names and occurrences specified by the topic link are valid.
NOTE 5 The scope attribute of the topic link architectural form is designed to permit a reduction in syntactic redundancy by
providing a means whereby the themes that are common to the scopes within which all the names and occurrences of a
topic are valid can be specified once for all. There is no requirement that it be used, however, even if its use would reduce
redundancy.
A valid topic link must have at least one of the following: a topic name, a topic occurrence, or a role played in an
association with at least one other valid topic.
The topic element type is derived from the varlink element type of the HyTime architecture.
NOTE 6 However, because it is possible to have a topic link without any occurs elements inside it, while (at the time of
publication of this International Standard) the HyTime architecture requires that varlink elements always contain at least one
anchspec, it is necessary that the value of the HyTime attribute be HyBrid when there are no contained occurs elements,
and that it be varlink when there are any such contained occurs elements. It is anticipated that future versions of the HyTime
architecture will permit varlink elements that contain no anchspec elements, and if such a change in the HyTime standard is
made, it will be possible to fix the value of the HyTime attribute of all topic elements at varlink.
The optional hyperlink type (linktype) attribute is defined by the HyTime architecture in order to allow the link
type name to be different from the generic identifier.
NOTE 7 Neither the value of the linktype attribute nor the generic identifier of a topic link has any significance with respect
to the topic mapping semantics defined by this International Standard.
topic      -- Topic link --
-- Clause: 5.2.1 --
- O
( topname | occurs)*
>
topic
©
10 ISO/IEC 2003 – All rights reserved

HyTime     -- HyTime architectural form name --
(varlink|HyBrid)
varlink   -- Constraint: varlink must be specified
when occurrences exist. If topic has no
occurrences, it must be declared as a
HyTime bridge element (HyBrid). --
id       -- Unique identifier --
ID
#REQUIRED
identity    -- Subject identity --
-- Reference to information (one or more
subject descriptors) that confers
understanding of the identity of the
subject of this topic link. --
CDATA    -- Reference --
#IMPLIED  -- Default: No subject descriptors; the
subject must be inferred from the
topic's characteristics. --
types     -- Topic types --
-- Topics whose subjects are the classes
of topics of which this topic is an
instance. --
CDATA    -- Reference --
-- Reftype: topic+ --
#IMPLIED  -- Default: No class-instance topic
associations are established via this
attribute. --
-- Note: Some might still be specified by
topic association links, however. --
scope     -- Scope --
-- The themes that are added to the scopes
of all the names and occurrences
specified by this topic link. --
CDATA    -- Reference --
-- Reftype: topic+ --
#IMPLIED  -- Default: No themes are added by this
attribute. --
linktype    -- Hyperlink type --
NAME
#IMPLIED  -- Default: Generic identifier --
>
5.3.2 Topic name architectural form
A topic may have zero or more name characteristics (topic names). Topic names are specified using topic
name (topname) elements; all such names become topic characteristics of the topic whose subject is the
subject of the containing topic link.
This International Standard distinguishes three kinds of topic name: base name (basename), display name
(dispname), and name used as sort key (sortname), specified by means of the three corresponding element
types that a topname element may contain.
The scope (scope) attribute of the topname element specifies the themes that are common to the scopes of all
of the topic name characteristics specified by the contained basename, dispname and sortname elements. The
scope is the context (or area of validity) in which the name characteristic(s) specified by a topname element
is/are assigned to the topic whose subject is the subject of the containing topic link.
©
ISO/IEC 2003 – All rights reserved 11

The scope attributes of the contained name elements (basename, dispname and sortname) may be used to
add more themes on a name-by-name basis, in the same manner as the scope attribute of the containing
topname element.
NOTE 1 Thus, the scope attribute of the topname element form is really just a means of avoiding the syntactic redundancy
of specifying the themes common to the contained elements separately via the scope attribute of each contained element.
NOTE 2 See also the definitions of “theme” and “scope” in 3.
If no scope attribute is specified by a basename, dispname or sortname element and no scope attribute is
specified by its containing topname nor by the containing topname's containing topic link, then the scope of the
name characteristic specified by that basename, dispname or sortname is unconstrained. If any of the
aforementioned scope attributes are specified, then the scope is constrained to the themes specified by those
scope attributes, even if the scope attributes specify no themes, plus any themes added via any applicable
addthms elements in the bounded object set, plus any themes added via the addthems attribute of the
containing topicmap document element.
The content of the optional display name (dispname) element specifies a name that is designed to be
displayed by an application to a user, when the name specified by the basename elements within the same
containing topname should not be used for display purposes.
NOTE 3 The display name can be used to specify an abbreviated name for use in situations where display resources are
limited, or it can be a graphic expressed in some data content notation.
The content of the optional name to be used as sort key (sortname) element specifies a name that is designed
to be used to represent the topic in a sorting process that arranges a list of topics in some order, when the name
specified by the basename elements within the same containing topname should not be used for that purpose.
NOTE 4 Thus, the basename elements, at least one of which is required, is also, in effect, the default content of the
optional dispname and sortname elements. If no dispname elements are specified, the basename elements are to be used
as display names. Similarly, if no sortname elements are specified, the basename elements are to be used as sort keys.
The data content of both basename and sortname elements must be text strings, and they may be words or
phrases. The data content of a dispname element may be either a text string or notation data; if it is notation
data, it may be a displayable graphic or other information intended to identify the subject to one or more of the
senses of the user of the topic map. If the content of a dispname is notation data, it must declare the notation
via the HyTime-defined notation common attribute (see ISO/IEC 10744:1997).
NOTE 5 There are two reasons why base names, display names, and names used as sort keys may share a single
containing topname element:
a) to allow them to share a common scope, specified via the scope attribute of the containing topname element, and/or
b) to indicate that base names, display names, and s
...