XML Topic Maps (XTM 1.0)

Spécification de TopicMaps.Org

Traduction française

Historique des versions
Version 1.016/07/2003Alain Herbuel

Rédaction première version de cette traduction. Création des CSS. Il faut bien commencer un jour !

Version 2.001/09/2003Alain Herbuel

Relecture et corrections, amélioration des CSS.

Version 3.009/09/2003Jean-Jacques Thomasson

Relecture et corrections.

Version 4.021/09/2003Alain Herbuel

Fusion des versions, retouche ponctuation et mise en forme, formatage des exemples.

Table des matières

- Note sur la traduction
- Résumé
- Statut de ce document
1 - Introduction
1.1 - Origines
1.2 - Objectifs
1.3 - Terminologie
2 - Concepts
2.1 - Introduction en douceur aux Topic Maps
2.2 - Aperçu des concepts des Topic Maps
2.2.1 - Topique
2.2.1.1 - Sujet
2.2.1.2 - Réification
2.2.1.3 - Identité de sujet
2.2.1.4 - Indicateur de sujet
2.2.1.5 - Caractéristique de topique
2.2.1.6 - Domaine de validité
2.2.2 - Nom
2.2.2.1 - Nom de base
2.2.2.2 - Variante de nom
2.2.2.3 - Paramètres
2.2.3 - Occurrence
2.3 - Association
2.3.1 - Membre
2.3.2 - Rôle
2.3.3 - Classe - instance
2.3.4 - Superclasse - sous-classe
2.4 - Topic Map
2.4.1 - Noeud d'une Topic Map
2.4.2 - Topic Map cohérente
2.4.3 - Document de type Topic Map
2.4.4 - Document XTM
2.5 - Sujets publiés
2.5.1 - Introduction
2.5.2 - Indicateurs XTM obligatoire de sujets publiés
2.6 - Fusion
3 - Documentation de la syntaxe XTM
3.1 - Introduction à la syntaxe XTM
3.2 - Références aux topiques et indicateurs de sujets
3.2.1 - L'élément <topicRef>
3.2.1.1 - Modèle de contenu
3.2.1.2 - Attributs
3.2.1.3 - Exemple
3.2.2 - Elément <subjectIndicatorRef>
3.2.2.1 - Modèle de contenu
3.2.2.2 - Attributs
3.2.2.3 - Exemples
3.3 - Domaine de validité et portée
3.3.1 - L'élément <scope>
3.3.1.1 - Modèle de contenu
3.3.1.2 - Attributs
3.3.1.3 - Exemples
3.4 - Classes et instances
3.4.1 - L'élément <instanceOf>
3.4.2 - Modèle de contenu
3.4.3 - Attributs
3.4.4 - Exemples
3.5 - La Topic Map
3.5.1 - L'élément <topicMap>
3.5.2 - Modèle de contenu
3.5.3 - Attributs
3.5.4 - Exemples
3.6 - Topiques et sujets
3.6.1 - L'élément <topic>
3.6.1.1 - Modèle de contenu
3.6.1.2 - Attributs
3.6.1.3 - Exemples
3.6.2 - L'élément <subjectIdentity>
3.6.2.1 - Modèle de contenu
3.6.2.2 - Attributs
3.6.2.3 - Exemples
3.7 - Noms de topiques
3.7.1 - L'élément <baseName>
3.7.1.1 - Modèle de contenu
3.7.1.2 - Attributs
3.7.1.3 - Exemples
3.7.2 - L'élément <baseNameString>
3.7.2.1 - Modèle de contenu
3.7.2.2 - Attributs
3.7.2.3 - Exemples
3.7.3 - L'élément <variant>
3.7.3.1 - Modèle de contenu
3.7.3.2 - Attributs
3.7.3.3 - Exemples
3.7.4 - L'élément <variantName>
3.7.4.1 - Modèle de contenu
3.7.4.2 - Attributs
3.7.4.3 - Exemples
3.7.5 - L'élément <parameters>
3.7.5.1 - Modèle de contenu
3.7.5.2 - Attributs
3.7.5.3 - Exemples
3.8 - Associations et membres
3.8.1 - L'élément <association>
3.8.1.1 - Modèle de contenu
3.8.1.2 - Attributs
3.8.1.3 - Exemples
3.8.2 - L'élément <member>
3.8.2.1 - Modèle de contenu
3.8.2.2 - Attributs
3.8.2.3 - Exemples
3.8.3 - L'élément <roleSpec>
3.8.3.1 - Modèle de contenu
3.8.3.2 - Attributs
3.8.3.3 - Exemples
3.9 - Occurences et ressources
3.9.1 - L'élément <occurence>
3.9.1.1 - Modèle de contenu
3.9.1.2 - Attributs
3.9.1.3 - Exemples
3.9.2 - L'élément <resourceRef>
3.9.2.1 - Modèle de contenu
3.9.2.2 - Attributs
3.9.2.3 - Exemples
3.9.3 - L'élément <resourceData>
3.9.3.1 - Modèle de contenu
3.9.3.2 - Attributs
3.9.3.3 - Exemples
3.10 - Fusion
3.10.1 - L'élément <mergeMap>
3.10.1.1 - Modèle de contenu
3.10.1.2 - Attributs
3.10.1.3 - Exemples
4 - Conformité
4.1 - Vocabulaire utilisé dans cette spécification
4.2 - Dépendances des traitements XTM
4.3 - L'espace de noms de XTM
4.4 - Conformité d'un document XTM
4.5 - Conformité d'une application XTM
Références bibliographiques
B - Modèle conceptuel XTM (informatif)
B.1 - Introduction
B.1.1 - Explication de la notation utilisée dans le modèle conceptuel
B.2 - Hiérarchie des classes
B.3 - Relation classe-instance
B.4 - Topique réifiant un sujet
B.5 - Référencer le sujet
B.6 - Domaine de validité des caractéristiques d'un topique
B.7 - Nom de base à l’intérieur d’un domaine de validité
B.8 - Occurence
B.9 - Association entre topiques
B.10 - Topic Map
C - Passage du modèle conceptuel XTM à une syntaxe d’échange concrète
D - Déclaration de type de document XTM 1.0 (normatif)
E - Noyau des indicateurs de sujets publiés de XTM 1.0 (normatif)
F - Spécification des traitements de documents XTM (informatif)
F.1 - Introduction
F.2 - Principes d'égalités
F.2.1 - Principle d'égalité des chaînes de caractères
F.2.2 - Principe d'égalité des URI
F.2.3 - Principe d'égalité des domaines de validité
F.2.4 - Principe d'égalité d'associations
F.2.5 - Principe d'égalité de nom de topique
F.2.6 - Principe d'égalité des occurrences de topiques
F.3 - Principes d'équivalences
F.3.1 - Equivalences entre <subjectIndicatorRef> et <topicRef>
F.3.2 - Equivalences entre <instanceOf> et <association>
F.3.3 - Equivalence de plusieurs membres (éléments <member>) d’un même rôle
F.4 - Opérations sur les variantes
F.4.1 - Traitement des variantes de domaine de validité
F.5 - Opérations de fusion
F.5.1 - Fusion de topiques
F.5.2 - Opération de fusion fondée sur les sujets
F.5.3 - Fusion fondée sur la contrainte de nomage des topiques
F.5.4 - Fusion explicite de Topic Map
F.5.5 - Fusion implicite de Topic Map
F.6 - Suppression de doublons
F.6.1 - Suppression des indicateurs de sujets doublons
F.6.2 - Suppression des noms de topiques doublons
F.6.3 - Suppression des associations doublons
F.6.4 - Suppression d’un acteur de rôle doublon
G - Transformation de document ISO 13250 vers XTM 1.0
H - Remerciements

Liste des illustrations

B.1 - Ligne se terminant par un triangle vide : d'un sous-type vers un type.
B.2 - Ligne se terminant éventuellement par une flèche : relation nommée
B.3 - Ligne se terminant par un losange noir : dépendance strict, appelée couramment relation de propriété (diagramme de classe)
B.4 - Ligne se terminant par un losange vide : un ensemble (diagramme de classe)
B.5 - Hiérarchie des classes (diagrammes de classes)
B.6 - Diagramme de classe d’une relation classe-instance
B.7 - Diagramme de classe d'un topique réifiant un sujet
B.8 - Diagramme de classe du référencement d'un sujet
B.9 - Diagramme de classe des domaines de validité des caractéristiques d'un topique
B.10 - Diagramme de classe des noms de base à l’intérieur d’un domaine de validité
B.11 - Diagramme de classe d’une occurrence
B.12 - Diagramme de classe d’une association de topiques
B.13 - Diagramme de classe d’une Topic Map

Liste des exemples

F.1 - Les URI des sujets adressables de A et B sont égales
F.2 - Les deux topiques ont en commun au moins un URI d’indicateur de sujet
F.3 - fusion de noms de topiques dans un domaine de validité non-contraint

Chapitre . Note sur la traduction

Ce document est une traduction de la recommandation XML Topic Maps (XTM) 1.0, datée du 06/08/2001. Cette version traduite peut contenir des erreurs absentes de l'original, introduites par la traduction elle-même. La version originelle en anglais, seule normative, se trouve à l'adresse http://www.topicmaps.org/xtm/1.0/xtm1-20010806.html.

Remerciements :

  • Pour les informations fournies : Michel Biezunski [mb@coolheads.com], Jean Delahousse [jean.delahousse@mondeca.com], et Bernard Vatant [bernard.vatant@mondeca.com].
  • Pour l'hébergement : XMLfr.org (l'espace xml francophone).

  • Pour la traduction :

    • Alain HERBUEL, KD Consult, MontBuisson, 01320, CRANS - Tél. : 06 71 72 40 05 - courriel : <kd_consult@yahoo.fr>
    • Jean-Jacques Thomasson, Sonovision-Itep, 86 rue Régnault Paris 13, tél : 01.44.23.14.50, courriel : <jthomasson@sonovision-itep.fr>

N'hésitez-pas à me remonter vos remarques ou erreurs rencontrées dans cette traduction.

Chapitre . Résumé

Cette spécification fournit un modèle et une grammaire pour représenter de manière structuréedes définitions de topiques et les relations qui les associent. Les topiques sont des sujets abstraits ayant comme caractéristiques des noms, des ressources et des relations. Les caractéristiques dépendent de domaines de validité qui en limitent la portée. Est appelé Topic Map un ensemble constitué de un ou plusieurs documents utilisant cette grammaire.

TopicMaps.Org est un consortium indépendant développant un modèle applicatif des Topic Maps [ISO13250] destiné au World Wide Web , cela en utilisant la specification XML et les technologies associées.

Cette spécification est la version 1.0 de XTM Topic Maps [XTM], un modèle abstrait utilisant la grammaire XTM pour l’interopérabilité des Topic Maps avec le Web. Elle est écrite par un groupe d'auteurs membres de TopicMaps.Org. Vous trouverez des précisions sur XTM et TopicMaps.Org à l'adresse http://www.topicmaps.org/about.html.

Toutes les versions de la spécification XTM sont disponibles sous licence publique, comme indiqué dans la charte de TopicMaps.Org.

Chapitre . Statut de ce document

Résumé

Le statut de ce document est valide au moment de sa publication. D'autres documents pourront venir le remplacer. Pour la dernière version, vous devez toujours vous référer à l'URL donnée ci-dessus.

Cette spécification a été revue par les auteurs du groupe de travail de TopicMaps.Org ainsi que par d'autres personnes morales ou physiques intéressées par ces travaux. Le groupe de travail de TopicMaps.Org l’a approuvé comme étant une spécification de TopicMaps.Org. Ce document est stable et peut donc être utilisée comme référence normative dans d’autres documents.

Seule la version anglaise de cette spécification est normative. TopicMaps.Org encourage toutefois vivement sa traduction.

Une liste de correctifs sera maintenue à l'adresse http://www.topicmaps.org/xtm/1.0/errata.html

Vous êtes priés de nous remonter les erreurs trouvées en écrivant à xtm-editor@topicmaps.org

Chapitre 1. Introduction

Table des matières

1.1 - Origines
1.2 - Objectifs
1.3 - Terminologie

1.1. Origines

XML Topic Maps (XTM) est le résultat des travaux du groupe de rédacteurs formé en 2000 par un consortium indépendant nommé TopicMaps.Org. Au départ, ce groupe était dirigé par Michel Biezunski et Steven R. Newcomb. A la date de livraison de cette spécification, il l’est par Steve Pepper et Graham Moore. La liste complète des membres ayant participé à ces travaux est fournie en annexe (voir Annexe H. Remerciements).

L'origine du concept de Topic Maps remonte à 1993 et se trouve dans un document de travail du goupe Davenport. Il fut ensuite repris et développé par l'institut de recherche du GCA (GCA Research Institute - connu aujourd'hui sous le nom de IDEAlliance) dans le cadre d’un groupe travaillant sur les Conventions d’applications de HyTime (Conventions for the Application of HyTime). Avant et après le concept fut développé de manière indépendante. Au début de l'année 2000, après plusieurs années d'efforts continus d'un groupe internationnal de personnes, le concept de cartes de topics pu être complètement formalisé sous la forme d’une norme ISO, sous la dénomination ISO/IEC 13250:2000. Presque immédiatement après, le consortium TopicMaps.Org fut créé afin de développer une application du concept pour le Webafin d’exploiter son énorme potentiel pour améliorer la recherche et la gestion de l'information sur le Web.

1.2. Objectifs

Les objectifs ayant prévalu à la conception de XTM sont :

Cette spécification, XML 1.0 pour la syntaxe de balisage [XML], XLink pour la syntaxe de lien [XLink], XML Base pour la résolution des URI [XMLBase], et la spécification IETF URI [RFC2396] (mise à jour par la spécification [RFC2732]), fournissent toutes les informations nécessaires à la compréhension de XTM 1.0 et la création de Topic Maps conformes.

La présente version de la spécification XTM et les informations associées peuvent être distribuées librement aussi longtemps que les textes et notices légales qui s’y rapportent resteront inchangés.

1.3. Terminologie

Le corps et les annexes de cette spécification contiennent des définitions terminologiques. Cette section présente les termes génériques utilisés dans ces définitions.

Ressource d'information adressable

Une ressource d’information dont l’identité peut être traitée par un ordinateur (c’est-à-dire qu’un ordinateur peut accéder à cette ressource, la comparer à d’autres et statuer sur leur égalité ou leur différence). Un exemple concret de ressource d’information adressable est la version en ligne de ce document. Les termes ressource et ressource d’information adressable sont indifféremment utilisés dans la présente spécification.

Sujet adressable

une ressource d’information adressable considérée comme sujet en elle-même, indépendamment de ce qu’en penserait ou dirait un auteur. L’identité d’un sujet adressable est, par définition, directement traitable par un ordinateur (voir sujet non adressable).

Association
Type d'association
  • L'une des classes d’association.
  • La classe d’association spécifiée par l’élément enfant <instanceOf> de l’élément <association>.
  • Un topique dont le sujet est une classe d’association.
Nom de base

Voir aussi Contrainte sur la dénomination de topique.

Caractéristiques

Voir caractéristique de topique.

Topic Map cohérente

Carte de topique dans laquelle il n’existe qu’un topique par sujet, et pas d’autre possibilité de fusion ou de suppression, telles que définies (voir Annexe F. Spécification des traitements de documents XTM (informatif)).

Membre
Fusion

Les règles qui régissent toutes les formes de fusions sont données en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).

Sujet non adressable

Un sujet hors de portée d’un ordinateur et dont l’identité est, par conséquent, impossible à traiter. Des exemples de sujet non adressables sont William Shakespeare, la pièce Hamlet, son édition 1604-05, le personnage de Hamlet, le concept de vengeance, l’organisation Shakespeare & Company, etc. L’identité d’un sujet non adressable peut seulement être établie indirectement, par exemple au moyen d’un indicateur de sujet.

Occurrence
Type d'occurrence
  • Une des classes d'occurrence de topique.
  • La classe d’occurrence de topique spécifiée par l’élément <instanceof> enfant d’un élément <occurrence>. Une occurrence ne peut appartenir qu’à une seule classe.
  • Un topique dont le sujet est une classe d’une occurrence de topique.
Paramètre
Topic Map traitée

L’ensemble des topiques, associations et domaines de validité ayant été traité par un processeur XTM comme défini en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).

PSI

Voir Indicateur de sujet publié.

Indicateur de sujet publié

Indicateur de sujet publié et maintenu à une adresse connue de tous dans le but de faciliter l’échange et la fusion de Topic Maps.

Réification

La réification est la manière avec laquelle on crée un topique. Quelque chose de réifié devient le sujet du topique ainsi créé. Ce faisant, il est possible d’affecter au sujet des caractéristiques via le topique qui le réifie. En d’autre termes, il devient possible de discourir à son sujet en utilisant les termes du concept des Topic Maps.

Ressource

Voir ressource d’information adressable.

Rôle

Rôle joué par un topique dans une association ; en tant que membre d’une association, le rôle d’un topique est la nature de son implication dans cette association.

Portée

Voir aussi contexte non contraint .

Cette spécification ne précise pas la manière dont les applications doivent interpréter les portées.

Sujet

Voire aussi identité de sujet, indicateur de sujet .

Identité de sujet
Indicateur de sujet

Une ressource qu’un auteur de Topic Map destine à être une indication positive et nette de l’identité d’un sujet. Il existe trois manière d’indiquer l’identité d’un sujet dans une carte de topique :

Le sujet indiqué par un indicateur de sujet peut être adressable ou non adressable (notez que dans le troisième cas, le sujet est forcément adressable puisqu’il s’agit d’une ressource).

Topique
  • Une ressource joue le rôle d’intermédiaire pour un sujet ; la représentation système d’un sujet dans le mécanisme des Topic Maps. La relation entre un topique et son sujet est définie comme étant une réification. La réification d’un sujet permet d’assigner des caractéristiques au topique qui le réifie.
Caractéristique d'un topique

Suivant le cas :

Les noms, occurrences et rôles des topiques sont collectivement connus comme étant ses caractéristiques.

Voir aussi nom de topique, occurrence de topique, et rôle.

Affectation de caractéristique de Topique

Le fait d’affecter des caractéristiques à un topique donné. Ces dernières étant valides par rapport à un certain domaine de validité.

Carte de topique
Document de type Topic Map

Document contenant une ou plusieurs Topic Maps conformes à cette spécification. Il peut être sérialisé pour des besoins de stockage ou d’échange.

Noeud d'un document de type Topic Map

Un objet (dans le système de représentation interne d’une carte de topique) qui représente un topique, une association ou un domaine de validité.

Nom de topique
Contrainte sur la dénomination de topique

La contrainte du concept de Topic Maps imposant que des topiques ayant le même nom de base dans le même domaine de validité se réfèrent au même sujet et devraient, de ce fait, être fusionnés.

Occurrence de topique

Une ressource spécifiée comme contenant une information relative à un certain topique. Afin de pouvoir être utilisée dans une Topic Map XTM, cette ressource doit être soit :

Type d'un topique
  • L’une des classe de topiques.
  • Une classe de topique spécifiée par l’élément<instanceOf>, enfant de l’élément <topique>. Un topique peut appartenir à plusieurs classes.
  • Un topique dont le sujet est une classe de topiques.
Portée non contrainte

La portée est non contraint quand elle n’est pas spécifiée au moment de l’affectation d’une caractéristique de topique.

Variant

Voir variante de nom.

Variante de nom

Forme alternative d’un nom de base rendue nécessaire par des traitements informatiques particuliers tels que des tris ou des affichages particuliers.

Document XTM

Un document de type Topic Map exprimé dans la syntaxe définie par la présente spécification.

Chapitre 2. Concepts

Table des matières

2.1 - Introduction en douceur aux Topic Maps
2.2 - Aperçu des concepts des Topic Maps
2.2.1 - Topique
2.2.1.1 - Sujet
2.2.1.2 - Réification
2.2.1.3 - Identité de sujet
2.2.1.4 - Indicateur de sujet
2.2.1.5 - Caractéristique de topique
2.2.1.6 - Domaine de validité
2.2.2 - Nom
2.2.2.1 - Nom de base
2.2.2.2 - Variante de nom
2.2.2.3 - Paramètres
2.2.3 - Occurrence
2.3 - Association
2.3.1 - Membre
2.3.2 - Rôle
2.3.3 - Classe - instance
2.3.4 - Superclasse - sous-classe
2.4 - Topic Map
2.4.1 - Noeud d'une Topic Map
2.4.2 - Topic Map cohérente
2.4.3 - Document de type Topic Map
2.4.4 - Document XTM
2.5 - Sujets publiés
2.5.1 - Introduction
2.5.2 - Indicateurs XTM obligatoire de sujets publiés
2.6 - Fusion

Cette section décrit les concepts dont la compréhension est nécessaire pour construire des Topic Maps (XTM).

L'objet d'une Topic Map est de transporter dans une couche indépendante des ressources la connaissance qui s’y rapporte. . Une Topic Map réunit les sujets traités par les ressources ainsi que les relations qui existent entre eux. Cela d'une façon totalement indépendante des méthodes de mise en œuvre.

Les concepts clés en sont les topiques (voir Section 2.2.1), les associations (voir Section 2.3) et les occurrences (Section 2.2.3).

Un topique est une ressource de votre ordinateur qui représente un objet du monde réel (on dit qu’il le « réifit »). Des exemples de tels sujets (voir Section 2.2.1.1) sont la pièce Hamlet, le dramaturge William Shakespeare, ou encore une relation de parternité.

Les topiques peuvent être nommés (voir Section 2.2.2) et avoir des occurrences, à savoir des ressources considérées comme ayant un rapport avec leur sujet. Enfin, les topiques peuvent participer à des relations, appelées associations, dans lesquelles ils jouent des rôles en tant que membres (voir Section 2.3.1).

Ainsi, les topiques peuvent avoir trois types de caractéristiques (voir Section 2.2.1.5) : les noms, les occurrences, et les rôles. L'affectation de ces caractéristiques peut toujours être relative à un domaine de validité particulier (voir Section 2.2.1.6).

Les Topic Maps peuvent être fusionnées, à la demande d'un utilisateur, d'une application au moment de son fonctionnement ou par un ordre issu du créateur de la Topic Map.

L’introduction de la section suivante présente un exemple simple pris dans le domaine des éditions encyclopédiques. Elle est suivie d’une présentation un peu plus détaillée du concept de Topic Maps. Les éléments XML utilisés par les Topic Maps sont, quant à eux, listés à la Section 3.1.

2.1. Introduction en douceur aux Topic Maps

Dans le but de rendre concrète l'utilisation des Topic Maps définie dans cette spécification, nous allons considérer l'exemple suivant. Supposons que nous voulions enregistrer, indépendamment d’une quelconque implémentation particulière, l'information relative à un sujet qui pourrait faire l’objet d’entrées d’index d'une encyclopédie électronique.

Pour des sujets comme par exemple William Shakespeare, Ben Jonson, leurs pièces Hamlet et Volpone, les villes de Londres et Stratford (pour n’en citer que quelques uns parmi des millers d'autres possibles), nous souhaitons noter toutes les parties de l'encyclopédie s’y référant, qu’il s’agisse de passages textuels, d’imagesou de séquences sonores ; et que le sujet soit directement abordé, mentionné ou seulement représenté. Pour désigner ces passages, nous utiliserons le terme d’occurrences de sujets. Différentes occurrences pouvant apporter différents types d'information, nous souhaitons pouvoir les distinguer : Discussions approfondies, brèves mentions et images peuvent être repérées de manière à offrir la possibilité à l'utilisateur de lancer des requêtes spécialisées et trouver plus rapidemment ce qu'il cherche.

L'encyclopédie imaginaire dont nous parlons existe sous forme électronique, chaque ressource d'information la constituant existe donc sous forme électronique, permettant ainsi d’effectuer des traitements informatiques (sans aller dans le détail concernant la nature d'une adresse de resssource, nous la définissons comme étant une expression, généralement courte permettant à un processeur adéquat d'accéder à la ressource). Nous parlons alors de ressource d'information adressable.

Les dramaturges William Shakespeare et Ben Jonson, par contraste, ne sont pas des ressources adressables : ils n’appartiennent pas au monde informatiques mais à celui du monde réel des humains. Afin de représenter le lien qui existe entre une occurrence et son sujet, nous voulons être capable de les pointer du doigt et dire « cette partie parle de tel sujet » (ou effectuer une manipulation équivalente dans un monde électronique en donnant des adresses aux sujets et aux occurrences et en décrivant les relations qui les relient en utilisant un langage particulier).

En ce qui concerne les sujets qui ne sont pas représentés dans le monde informatique, il est impossible de leur attribuer des adresses électroniques. A la place, nous attribuons au sujet un substitutqui peut avoir une adresse : Nous l'appelons « topique ». Chaque topique n'est là que comme substitut d'un sujet. Nous disons qu’il réifie le sujet, ou qu’il le rend réel pour le système informatique. La création d'un topique réifiant un sujet permet de le manipuler par programme, le traiter informatiquement et de lui attribuer des caractéristiques additionnelles. Pour faire référence à un sujet, nous donnons une adresse électronique au topique qui le réifie, et agit comme étant son remplaçant au sein du système.

Afin que vous ne fassiez pas de confusion nous utiliserons parfois les termes topique et sujet de manière équivalente ; puisque chaque topique réifie un sujet et que chaque sujet peut être réifié par un topique, la différence n'est pas toujours importante.

Considérant que l’ensemble des entrées de l’index de notre encyclopédie constitue en quelque sorte la carte des sujets de notre encyclopédie, permettant de connaître très précisément les endroits où chaque sujet est mentionné et discuté, nous l’appelons « Topic Map ».

Des topiques représentant quelques pièces de William Shakespeare pourraient être représentés de la manière suivante.

<topic id="hamlet">
    <instanceOf><topicRef xlink:href="#play"/></instanceOf>
    <baseName>
      <baseNameString>Hamlet, Prince of Denmark</baseNameString>
    </baseName>
    <occurrence>
      <instanceOf><topicRef xlink:href="#plain-text-format"/></instanceOf>
      <resourceRef
        xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt"/>
    </occurrence>
  </topic>

  <topic id="tempest">
    <instanceOf><topicRef xlink:href="#play"/></instanceOf>
    <baseName>
      <baseNameString>The Tempest</baseNameString>
    </baseName>
    <occurrence>
      <instanceOf><topicRef xlink:href="#plain-text-format"/></instanceOf>
      <resourceRef
        xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws4110.txt"/>
    </occurrence>
  </topic>
Afin d’avoir des exemples courts, les URI dans cette spécification ne contiennent parfois que des identificateurs de fragments (c’est le cas de play ci-dessus). Nous supposons qu’ils renvoient à un élément <topic> de la même Topic Map possédant un attribut id de même valeur.

Dans les thésaurus et index de sujets, il est utile d’exprimer des relations entre sujets : Hamlet et The Tempest sont des exemples de pièces, Shakespeare en est l’auteur, Rosencrantz et Guildenstern sont des personnages d’Hamlet, etc. Dans les travaux de référencement, ces types de relations sont classiquement utilisés comme base de références croisées. Notez que ces relations ne sont pas établies entre les occurrences des sujets mais entre les sujets eux-mêmes ; leur représentation électronique de est indépendante des occurrences et peut être appliquée à des types très différents d'occurrences. Elle prendra la forme de relations, ou associations, entre topiques.

Une relation entre Shakespeare et Hamlet, sa pièce, pourrait prendre la forme suivante.

<association>
    <instanceOf><topicRef xlink:href="#written-by"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#author"/></roleSpec>
      <topicRef xlink:href="shakespeare"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#work"/></roleSpec>
      <topicRef xlink:href="hamlet"/>
    </member>
  </association>

Il s’agit d’une association établissant une relation entre différents topiques. Tel que cela est fait, il existe une relation bi-directionnelle intrinsèque : si Hamlet a été écrit par Shakespeare, alors Shakespeare a écrit Hamlet. Dans les deux relations, la même chose est exprimée de manière différente. Au lieu de parler de direction, nous utilisons l'idée de rôle rempli par chacun des membres d’une relation ou d’une association. Ainsi, l'exemple ci-dessus peut être exprimé en langage natuel de la manière suivante : « il existe une relation "écrit par" entre Shakespeare, jouant le rôle de "auteur", et Hamlet, jouant le rôle "d’œuvre" ». Les relations peuvent être établies entre un, deux ou plusieurs rôles.

Il n'y a pas de limite aux types de relations que nous pouvons prendre en considération ; dans certains cas de figures, des relations de type « à vécu à » et « est un exemple de » suffiront tandis que dans d’autres cas de figure, un plus grand nombre de relations sera nécessaire.

Les topiques et leurs relations pouvant être décrits de manière indépendante des occurrences, un même ensemble de topiques peut être connecté, via différentes applications, à différentes ressources. Inversement, un ensemble de ressources peut être connecté à différentes Topic Maps. Un même sujet peut être représenté par différents topiques dans différentes Topic Maps ; cela sera important quand il faudra fusionner des Topic Maps spécifiant le même sujet.

A un niveau d'abstraction plus élevé, notre encyclopédie peut être vue comme étant un ensemble de ressources d'informations adressables, chacune d’elles se trouvant à l’intérieur d’un ensemble de ressources d'informations adressables plus large, et chacune concernant un ou plusieurs sujets. Notre index de sujets est alors constitué de trois types d’objets :

  1. un jeu de topiques dont chacun est un substitut d’un sujet (il le réifie), et peut avoir un ou plusieurs noms ;
  2. des liens entre les topiques et les ressources d'informations qui sont les occurrences des sujets réifiés par lestopiques (des exemples sont « traité dans », « mentionné dans », « représenté dans », etc.) ;
  3. des associations entre les topiques (des exemples sont « exemple de », « écrit par », « vit à »).

Le terme Topic Map désigne un ensemble de tels objets. Notez qu’un sujet est tout ce à quoi un humain peut penser, discuter ou représenter sous forme électronique. Aucun mécanisme n’existe pour déterminer si deux sujets sont identiques ou différents ou si deux topiques réifient le même sujet. En consequence, les sujets eux-mêmes ne sont pas apparents dans la descrioption formelle fournie. Nous n’essayons pas non plus de restreindre la nature des relations entre les topiques et leurs occurrences ou entre les topiques. Pour cette raison, le formalisme défini ici, bien qu’initialement issu des travaux relatifs à la recherche d’information dans des masses d’objets multimedia, s’applique à de nombreux autres cas de figure (ou qui semblent) très éloignés des seuls preoccupations d’indexation des encyclopédies. La terminologie continue de nos jours à réfléter les origines historiques des termes pour des besoins de clarification et de concrétisation.

Vous noterez que les ressources informatiques quelles que’elles soient peuvent elles mêmes faire l’objet de notre attention, elles peuvent être traitées comme étant des topiques. Une peinture représentant William Shakespeare, par exemple, est simplement une occurrence du topique représentant William Shakespeare, mais on peut aussi mentionner, en tant que peinture, dans une histoire de l’Art, ou dans une discussion sur les formats graphiques, ou encore dans un inventaire de ressources électroniques — ou enfin dans une Topic Map.)

2.2. Aperçu des concepts des Topic Maps

2.2.1 - Topique
2.2.1.1 - Sujet
2.2.1.2 - Réification
2.2.1.3 - Identité de sujet
2.2.1.4 - Indicateur de sujet
2.2.1.5 - Caractéristique de topique
2.2.1.6 - Domaine de validité
2.2.2 - Nom
2.2.2.1 - Nom de base
2.2.2.2 - Variante de nom
2.2.2.3 - Paramètres
2.2.3 - Occurrence

Cette section est un tour d’horizon de tous les concepts mis en œuvre dans l’élaboration des Topic Maps. Il est très largement basé sur les définitions faites dans la section sur la terminologie (voir Section 1.3), mais ceux-là sont ici présentés dans un ordre logique plutôt qu’alphabétique. Cette section contient par ailleurs des précisions supplémentaires.

2.2.1.1 - Sujet
2.2.1.2 - Réification
2.2.1.3 - Identité de sujet
2.2.1.4 - Indicateur de sujet
2.2.1.5 - Caractéristique de topique
2.2.1.6 - Domaine de validité

Un topique est une ressource qui agit comme le représentant local d’un sujet (voir Section 2.2.1.1) ; c'est la représentation système d’un sujet pour une carte de topique. La relation entre un topique et son sujet est définie comme étant une réification (Section 2.2.1.2). La réfification d'un sujet permet de lui affecter des caractéristiques (voir Section 2.2.1.5).

Chaque topique est une instance de une ou plusieurs classes de topiques (au connus sous le nom de types de topiques) indiqués explicitement ou non. Le type de topique par défaut est défini par le sujet publié pour ce topique (voir Section 2.5).

Un sujet est toute chose qu’un homme peut discuter ou concevoir. De façon la plus générique possible, on dira un sujet peut être n'importe quoi, que cette chose existe ou non et qu’on puisse la caractériser ou non, et indépendamment du sens qu’on puisse lui donner. En particulier, il peut s'agir de tout ce qui peut intéresser l’auteur d'une Topic Map.

Afin de pouvoir concrétiser la notion de sujet dans le concept de Topic Maps, il doit être réifié ; ce qui se fait au travers du mécanisme de création de topiques. Les sujets constituent ainsi le principe structurant des topiques.

Dans une Topic Map cohérente, chaque sujet est représenté par un seul topique. Dans un document de type Topic Map par contre, plusieurs topiques peuvent réifier le même sujet (dans ce cas, ils est préférable qu’ils puissent être ramenés à un seul topique pendant le traitement).

La plupart des sujets n’existent qu’en dehors du monde de l'ordinateur ; ils ne peuvent donc pas être adressables directement et leurs identités ne peut donc pas être traité par programme. Des exemples de tels sujets non-adressables sont par exemple William Shakespeare, la pièce Hamlet et son édition 1604-05, le rôle de Hamlet, le concept de vengeance, la société Shakespeare & Company, cette spécification XTM, etc. L'identité des sujets non-adressables ne peut être établie qu'indirectement au travers d'une ressource fonctionnant comme indicateur de sujet (voir Section 2.2.1.4).

Cependant, tout peut donner lieu à sujet dans une Topic Map, y compris les ressources de l’ordinateur elles-mêmes. Les ressources considérées comme sujets sont appelées sujets adressables. Un exemple de sujet adressable est cette spécification XTM car le document HTML correspondant est accessible informatiquement.

L'acte de création d’un topique est appelé réification. Une chose réifié devient le sujet du topique qui la réifie. Réifier quelque chose revient ainsi à créer un topique dont le sujet est la chose en question. Le fait de réifier un sujet permet de lui affecter des caractéristiques via le topique qui le réifie. En d’autres termes, il devient possible de discourir à propos de ce sujet avec les mécanismes du concept de Topic Maps.

La notion de réification est au coeur du concept de Topic Maps. La seule façon qui existe de parler de quelque chose dans une Topic Map est de créer un topique et lui affecter des caractéristiques. Les topiques permettent de donner corps à des notions abstraites au sein de votre système. ce faisant ces choses « réelles » pour l’humain deviennent également « réelles » pour votre ordinateur.

N'importe quoi pouvant être un sujet, la réification peut s’appliquer à tout objet contenu dans une Topic Map. Il en est ainsi des associations, noms et occurrences (pour des exemples de mise en œuvre syntaxique, se référer aux descriptions des éléments <association> et <occurrence> au Chapitre 3. Documentation de la syntaxe XTM). Cela est rendu possible par la puissance intrinsèque du concept de Topic Maps, qui offre la possibilité de gérer des connaissances sur la connaissance elle-même.

L’identification d’un sujetest un mécanisme permettant d'établir un lien entre un sujet et les topiques qui le réifient. Quand deux topiques ont la même identité de sujet, on considère qu’ils parlent de la même chose et doivent par conséquent être fusionnés. Les Topic Maps devant être « fusionnables » — pour échanger leurs sémantiques —, le concept de Topic Map va le plus loin possible pour définir de manière fiable l'identité d'un topique (et par là de son sujet).

L'identité d'un sujet peut être établie de deux façons différentes :

  1. En adressant directement le sujet. Cela est possible lorsque le sujet est une ressource d'information adressable.
  2. En indiquant le sujet via un indicateur de sujet (voir Section 2.2.1.4).

Un indicateur de sujet est une ressource dont l’auteur d’une carte de topique pense qu’elle est une identification non ambigüe d’un sujet. Lorsque deux topiques font référence à la même ressource pour indiquer leur sujet, ils parlent, par définition, de la même chose, et doivent donc être fusionnés lors des traitements.

L'identification des sujet étant à la base du mécanisme de fusion des Topic Maps, les auteurs sont encouragés à déclarer les identités des sujets de leurs topiques de la manière la plus fiable possible, en particulier en utilisant les indicateurs de sujets publiés (voir Section 2.5).

Un même sujet pouvant être identifié de plusieurs manières, il est possible que deux topiques réifient le même sujet en utilisant des indicateurs de sujets différents ; ils ne pourront dès lors être fusionnés. L'utilisation d'un troisième topique permet d’éviter de telles situations (ce troisième topique peut être situé dans la même Topic Map ou dans une autre), établissant sont identité via les deux indicateurs de sujet. Ce mécanisme est utilisé pour fusionner des ontologies différentes.

Dans le concept de Topic Maps , tout ce qui peut être directement rattaché à un topique est une caractéristique d'un topique. Il existe trois types de caractéristiques :

La validité des caractéristiques affectées à un topique dépend d'un domaine de validité (voir Section 2.2.1.6).

Le domaine de validité définit la portée de la validité d'une caractéristique de topique. Il fixe les limites dans lesquelles un nom, une occurrence est un rôle sont assignés à un topique. Chaque caractéristique a un domaine de validité propre explicite ou implicite ; dans ce dernier cas, on dit que le domaine de validité est non-contraint. Les caractéristiques affectées sans précision de domaine de validité sont toujours valides.

Pour les noms de base des topiques, le domaine de validité fait office d’espace de nom. Cela nous amène à une contrainte générique du concept de Topic Maps appelée contrainte sur la dénomination de topique. Cette règle d’unicité précise que deux topiques ayant le même nom de base dans le même domaine de validité réfèrent au même sujet, et devraient donc être fusionnés. A l’exception de cette contrainte, l’interprétation de la portée d’une caractéristique est entièrement laissée à la charge des applications et n’est en rien limitée par cette spécification.

2.2.2.1 - Nom de base
2.2.2.2 - Variante de nom
2.2.2.3 - Paramètres

Un topique peut avoir zéro ou plusieurs noms, chacun étant valide dans un certain domaine de validité (y compris s’il s’agit du domaine de validité non-contraint).

Un nom peut prendre plusieurs formes. Il existe toujours une forme de base, connu comme étant le nom de base (voir Section 2.2.2.1), à laquelle peut venir se rajouter une ou plusieurs variantes (voir Section 2.2.2.2) pouvant être utilisées dans des domaines de validité particuliers de traitements.

Le nom de base est la forme de base d'un nom de topique. Lorsqu'une application a besoin de manipuler un topique par son nom, c’est par défaut le nom de base qui est une chaîne de caractère qui est utilisé. Une application pourra utiliser une variante de nom, si elle existe, s’il s’avère que cette forme est plus pertinente dans son environnement d’excécution.

Les noms de base sont partie prenante de la règle de nommage des topiques, interdisant qu'une Topic Map après traitement possède plusieurs topiques comportant le même nom dans le même domaine de validité.

Une variante de nom est une alternative au nom de base optimisée pour un traitement particulier, par exemple pour effectuer des tris ou des affichages. Elle peut être n'importe quelle type de ressource, y compris une chaîne de caractères. Les applications choisissent les variantes de noms en fonction de leurs paramètres (voir Section 2.2.2.3).

Les paramètres sont des informations exprimées sous la forme d'un ensemble de topiques servant à définir le domaine de validité approprié à la prise en compte d’une variante de nom (voir Section 2.2.2.2). A partir du nom d'un topique, une application peut examiner les paramètres de ses variantes de noms (si elles existent) afin de choisir une forme plus appropriée de ce nom.

Une occurrence est une information définie comme pertinente pour un sujet donné. L’occurrence est l’une des trois caractéristiques (voir Section 2.2.1.5) possible d’un topique, elle est par conséquent liée à un domaine de validité (voir Section 2.2.1.6). Une occurrence est une instance d'une classe d'occurrences (dénommée type d'occurrence) qui est définie explicitement ou implicitement. Le type d'occurrence par défaut est définie par le sujet publié dénommé « occurrence » (voir Section 2.5).

Pour être manipulées dans une Topic Map, une occurrence doit être une ressource qui :

  1. 1. soit est référençable via un URI (une « ressource de type référence »),
  2. 2. soit peut être mise en ligne sous la forme d’une chaîne de caractères (il s’agit alors d’une « ressource de type donnée »).

La deuxième approche est utile dans le cas où l’information relative à un sujet est courte (par exemple la date d’écriture d'une pièce).

2.3. Association

2.3.1 - Membre
2.3.2 - Rôle
2.3.3 - Classe - instance
2.3.4 - Superclasse - sous-classe

Une assocoication est une relation entre un ou plusieurs topiques, chacun d'entres-eux jouant un rôle (voir Section 2.3.2) en tant que membre (voir Section 2.3.1) de cette association. Les rôles que jouent les topiques dans les associations sont une de leurs caractéristiques (voir Section 2.2.1.5), dépendant ainsi de la notion de contexte (voir Section 2.2.1.6). Chaque association est une instance d'une seule classe d'association (nommée aussi type d'association), celui-ci pouvant être précisé de manière explicite ou implicite. Le type d'association par défaut est définie en Section 2.5.

Une association n’a pas de sens. Une association décrit des relations et si A est relié à B, alors B est relié à A. La question est plutôt de connaître le type de l’association et quels sont les rôles joués par les membres. La question de savoir comment nommer une relation relève d'un problème de nomage, non de direction de celle-là.

Le concept de rôle exprime la nature de l'implication d'un topique en tant que membre d’une association.

Classe-instance est une association qui exprime une relation de type classe / instance entre des topiques jouant respectivement les rôles de classe et d'instance. Les sujets « classe / instance » (voir ???), classe ( voir Section 3.4) et instance (voir Section 3.4.1) sont tous définis dans cette spécification au moyen d’indicateurs de sujets publiés (PSI).

Superclasse-sous-classe est une classe d'associations pour exprimer une relation entre topiques jouant respectivement les rôles de superclasse et de sous-classe. Les sujets relation superclasse-sous-classe, superclasse et sous-classe sont tous définis par des indicateurs de sujets publiés définis ici-même.

2.4. Topic Map

2.4.1 - Noeud d'une Topic Map
2.4.2 - Topic Map cohérente
2.4.3 - Document de type Topic Map
2.4.4 - Document XTM

Une Topic Map est ensemble de topiques, d'associations, et de domaines de validité (globalement appelés noeuds de carte de topiques, pouvant exister sous une ou deux formes :

  1. 1. un format d'échange sérialisé (e.g. un document de type Topic Map exprimé en XTM ou dans une autre syntaxe) ;
  2. une forme interne à une application, contraintes par les caractéristiques de traitements XTM définies en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).

Le but d'une Topic Map est de "transporter" un ensemble de connaissances à propos de ressources, ceci dans une couche, ou une carte, "au dessus" des ressources elles-mêmes. Une Topic Map capture des sujets desquels parlent les ressources en question, et les relations existant entre ces sujets, ceci dans une forme indépendante des implémentations.

Les noeuds d'une Topic Map sont les objets créés pour la représentation interne à un système d'une Topic Map. Ils représentent les topiques (voir Section 2.2.1), les associations (voir Section 2.3) et les domaines de validité (voir Section 2.2.1.6).

Une Topic Map cohérente ne contient qu'un seul topique par sujet, et aucune possibilité de suppression de doublons ou de fusion de topiques, tel que ces mécanismes sont présentés en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).

Un document de type Topic Map est un document qui contient une ou plusieurs Topic Maps se conformant à la présente spécification. A des fins de le stockage ou d’échange, il peut être sérialisé dans une syntaxe pouvant être celle de la courante spécification, voire d'une autre.

Un document XTM est un document de type Topic Map exprimé dans la syntaxe définie par la présente spécification.

2.5. Sujets publiés

2.5.1 - Introduction
2.5.2 - Indicateurs XTM obligatoire de sujets publiés

Un sujet est « publié » quand son indicateur de sujet (voir Section 2.2.1.4) a été rendu publiquement utilisable et qu’il est accessible en ligne via un URI. Un indicateur de sujet publié est ainsi n'importe quelle ressource ayant été publiée dans le but de fournir une indication claire et nette de l’identité du sujet, cela afin d'échanger ou de fusionner des Topic Maps.

Certains sujets sont consubstantiels à cette spécification. Plusieurs contraintes imposées par cette spécification sont exprimées au travers de sujets publiés, y compris les classes par défaut des topiques, associations et occurrences, ainsi que l'équivalence entre l'utilisation de <instanceOf> et une association du type <class-instance> dans le domaine de validité non-contraint.

Les indicateurs de sujets publiés fournis par cette spécification pour les sujets XTM obligatoires sont brièvement identifiés dans cette section. Les descriptions fournies ci-après sont référencées en tant qu'indicateurs de sujets par les éléments <topic> contenus dans la Topic Map fournie en annexe (voir Annexe E. Noyau des indicateurs de sujets publiés de XTM 1.0 (normatif)).

topique

Le concept de base de topique ; la classe générique à laquelle appartiennent par défaut tous les topiques.

http://www.topicmaps.org/xtm/1.0/core.xtm#topic

association

Le concept de base d'association ; la classe générique à laquelle appartiennent par défaut toutes les associations.

http://www.topicmaps.org/xtm/1.0/core.xtm#association

occurrence

Le concept de base d’occurrence ; la classe générique à laquelle appartiennent par défaut toutes les occurrences.

http://www.topicmaps.org/xtm/1.0/core.xtm#occurrence

relation classe / instance

Le concept de base de relation classe-instance ; la classe d'association qui représente les relations entre de classes à instances entre topiques, et qui est sémantiquement équivalente à l'utilisation de la balise de sous-élément <instanceOf>.

http://www.topicmaps.org/xtm/1.0/core.xtm#class-instance

classe

Le concept de base de classe ; le rôle de classe tenu par l’un des membres d'une association de type classe-instance.

http://www.topicmaps.org/xtm/1.0/core.xtm#class

instance

Le concept de base d'instance; le rôle d'instance tenu par l’un des membres d'une association de type classe-instance.

http://www.topicmaps.org/xtm/1.0/core.xtm#instance

relation superclasse / sous-classe

Le concept de base de superclasse-sous-classe ; la classe d'association qui représente les relations superclasses-sous-classes entre les topiques.

http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass

superclasse

Le concept de base de superclasse ; le rôle de superclasse tenu par l'un des membres d'une relation de type superclassesous-classes.

http://www.topicmaps.org/xtm/1.0/core.xtm#superclass

sous-classe

Le concept de base de sous-classe ; le rôle de sous-classe tenu par l’un des membres d’une association superclasse-sous-classe.

http://www.topicmaps.org/xtm/1.0/core.xtm#subclass

aptitude pour le tri

Aptitude d’un topique à être utilisé comme clé de tri ; à utiliser dans les paramètres des variantes de noms.

http://www.topicmaps.org/xtm/1.0/core.xtm#sort

aptitude pour l'affichage

Aptitude d’un nom de topique à être affiché ; à utiliser dans les paramètres des variantes de noms.

http://www.topicmaps.org/xtm/1.0/core.xtm#display

2.6. Fusion

Le terme fusionner couvre deux traitements distincts :

  1. La fusion de deux Topic Maps, provoquée par un ordre explicite <mergeMap> ou par des raisons propres à une application.
  2. La fusion de deux topiques.

Les règles propres aux fusions et la détermination de l'identité de sujet sont données en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)). Elles peuvent être rapidement et de manière incomplète, résumées comme suit :

  1. Lors de la fusion de deux Topic Maps, l'application, peu importe comment, détecte les sujets identiques, les fusionne, et supprime les associations dupliquées.
  2. Lors de la fusion de deux topiques, le résultat est un seul topique dont les caractéristiques sont l'union des caractéristiques des topiques originaux, les doublons étant supprimés.

Deux topiques sont considérés comme ayant le même sujet si :

  1. ils ont un ou plusieurs indicateurs de sujets commun ;
  2. ils réifient le même sujet adressable ;
  3. ils possèdent le même nom de base dans le même domaine de validité.

Chapitre 3. Documentation de la syntaxe XTM

Table des matières

3.1 - Introduction à la syntaxe XTM
3.2 - Références aux topiques et indicateurs de sujets
3.2.1 - L'élément <topicRef>
3.2.1.1 - Modèle de contenu
3.2.1.2 - Attributs
3.2.1.3 - Exemple
3.2.2 - Elément <subjectIndicatorRef>
3.2.2.1 - Modèle de contenu
3.2.2.2 - Attributs
3.2.2.3 - Exemples
3.3 - Domaine de validité et portée
3.3.1 - L'élément <scope>
3.3.1.1 - Modèle de contenu
3.3.1.2 - Attributs
3.3.1.3 - Exemples
3.4 - Classes et instances
3.4.1 - L'élément <instanceOf>
3.4.2 - Modèle de contenu
3.4.3 - Attributs
3.4.4 - Exemples
3.5 - La Topic Map
3.5.1 - L'élément <topicMap>
3.5.2 - Modèle de contenu
3.5.3 - Attributs
3.5.4 - Exemples
3.6 - Topiques et sujets
3.6.1 - L'élément <topic>
3.6.1.1 - Modèle de contenu
3.6.1.2 - Attributs
3.6.1.3 - Exemples
3.6.2 - L'élément <subjectIdentity>
3.6.2.1 - Modèle de contenu
3.6.2.2 - Attributs
3.6.2.3 - Exemples
3.7 - Noms de topiques
3.7.1 - L'élément <baseName>
3.7.1.1 - Modèle de contenu
3.7.1.2 - Attributs
3.7.1.3 - Exemples
3.7.2 - L'élément <baseNameString>
3.7.2.1 - Modèle de contenu
3.7.2.2 - Attributs
3.7.2.3 - Exemples
3.7.3 - L'élément <variant>
3.7.3.1 - Modèle de contenu
3.7.3.2 - Attributs
3.7.3.3 - Exemples
3.7.4 - L'élément <variantName>
3.7.4.1 - Modèle de contenu
3.7.4.2 - Attributs
3.7.4.3 - Exemples
3.7.5 - L'élément <parameters>
3.7.5.1 - Modèle de contenu
3.7.5.2 - Attributs
3.7.5.3 - Exemples
3.8 - Associations et membres
3.8.1 - L'élément <association>
3.8.1.1 - Modèle de contenu
3.8.1.2 - Attributs
3.8.1.3 - Exemples
3.8.2 - L'élément <member>
3.8.2.1 - Modèle de contenu
3.8.2.2 - Attributs
3.8.2.3 - Exemples
3.8.3 - L'élément <roleSpec>
3.8.3.1 - Modèle de contenu
3.8.3.2 - Attributs
3.8.3.3 - Exemples
3.9 - Occurences et ressources
3.9.1 - L'élément <occurence>
3.9.1.1 - Modèle de contenu
3.9.1.2 - Attributs
3.9.1.3 - Exemples
3.9.2 - L'élément <resourceRef>
3.9.2.1 - Modèle de contenu
3.9.2.2 - Attributs
3.9.2.3 - Exemples
3.9.3 - L'élément <resourceData>
3.9.3.1 - Modèle de contenu
3.9.3.2 - Attributs
3.9.3.3 - Exemples
3.10 - Fusion
3.10.1 - L'élément <mergeMap>
3.10.1.1 - Modèle de contenu
3.10.1.2 - Attributs
3.10.1.3 - Exemples

3.1. Introduction à la syntaxe XTM

La syntaxe pour sérialiser et échanger des documents de type Topic Map conformes à cette spécification est définie par la DTD XML donnée en annexe (voir Annexe D. Déclaration de type de document XTM 1.0 (normatif)). Cette section contient la documentation de tous les types d'éléments définis dans cette DTD.

La liste ci-après est représentée dans l'ordre dans lequel ils sont documentés :

  • <topicRef> : référence à un topique.
  • <subjectIndicatorRef>: référence à un indicateur de sujet.
  • <scope> : référence à un ou plusieurs topiques définissant la portée.
  • <instanceOf> : pointeur vers un topique représentant une classe.
  • <topicMap> : élément racine d'une Topic Map.
  • <topic> : élément topique.
  • <subjectIdentity> : sujet réifié par un topique.
  • <baseName> : nom de base d'un topique.
  • <baseNameString> : conteneur d'une chaîne de caractères représentant le nom de base d’un topique.
  • <variant> : formes alternatives du nom de base.
  • <variantName> : conteneur pour variante de nom.
  • <parameters> : domaine de validité des traitements des variantes.
  • <association> : association de topique.
  • <member> : membre dans une association de topique.
  • <roleSpec> : pointeur vers un topique servant de rôle d'association.
  • <occurrence> : ressources vues comme des occurences.
  • <resourceRef> : référence à une ressource.
  • <resourceData> : conteneur pour une ressource de type donnée.
  • <mergeMap> : fusion avec une autre Topic Map.

3.2. Références aux topiques et indicateurs de sujets

3.2.1 - L'élément <topicRef>
3.2.1.1 - Modèle de contenu
3.2.1.2 - Attributs
3.2.1.3 - Exemple
3.2.2 - Elément <subjectIndicatorRef>
3.2.2.1 - Modèle de contenu
3.2.2.2 - Attributs
3.2.2.3 - Exemples
3.2.1.1 - Modèle de contenu
3.2.1.2 - Attributs
3.2.1.3 - Exemple

L'élément <topicRef> fournit une référence à un topic via son URI. La cible d'un lien <topicRef> doit se ramener à un élément <topic> enfant de l'élément racine <topicMap> d’un document de type Topic Map conforme à cette spécification. Il n’est pas obligatoire que la cible <topic> soit dans le même document que la source.

Les éléments <topicRef> sont identiques aux éléments <subjectIndicatorRef>, à l’exception de la contrainte qui leur impose de pointer vers un élément <topic>.

Apparaît dans : <instanceOf>, <member>, <mergeMap>, <parameters>, <roleSpec>, <scope>, <subjectIdentity>

<!ELEMENT topicRef  EMPTY >

L'élément <topicRef> est vide.

  <!ATTLIST topicRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

L'élément <topicRef> possède les attributs suivants :

id

Identificateur unique de l'élément.

xlink:type

Identifie le lien comme étant un lien XLink de type simple.

xlink:href

Contient l’URI de la cible de ce lien.

Note

Voir les sections 5.2 et 5.4 de [XLink] pour les questions d’utilisation et de conformité.

Référence à un topique ayant l'identificateur en dans le document language.xtm (c'est en fait un sujet publié pour la langue anglaise) :

<topicRef
    xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>

ayant l'identificateur play physiquement localisé dans le document courant :

<topicRef xlink:href="#play"/>

Vous trouverez d’autres exemples avec les éléments <scope>, <instanceOf>, <variant>, <association>, et <mergeMap>.

3.2.2.1 - Modèle de contenu
3.2.2.2 - Attributs
3.2.2.3 - Exemples

L'élément <subjectIndicatorRef> contient l’URI d’une ressource qui est un indicateur de sujet.

Apparaît dans : <instanceOf>, <member>, <mergeMap>, <parameters>, <roleSpec>, <scope>, <subjectIdentity>.

<!ELEMENT subjectIndicatorRef  EMPTY >

L'élément <subjectIndicatorRef> est vide.

<!ATTLIST subjectIndicatorRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRE
>

L'élément <subjectIndicatorRef> possède les attributs suivants :

id

identificateur unique de l'élément.

xlink:type

Identifie le lien comme étant un lien XLink de type simple.

xlink:href

Contient l’adresse URI de ce lien.

Note

Voir les sections 5.2 et 5.4 de [XLink] pour les questions relatives à l’utilisation et la conformité.

Référence à un indicateur de sujet publié :

<subjectIndicatorRef
    xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>

Référence à une ressource (fictive) qui indique un sujet de manière moins formelle :

<subjectIndicatorRef
    xlink:href="http://www.shakespeare.org/plays.html#hamlet"/>

Pour plus d'exemples, voir <scope>, <instanceOf>, <subjectIdentity>.

Pour obtenir des exemples sur la manière d'utiliser <subjectIndicatorRef> pour réifier des montages de Topic Map, voir les éléments <association> et <occurence>.

3.3. Domaine de validité et portée

3.3.1 - L'élément <scope>
3.3.1.1 - Modèle de contenu
3.3.1.2 - Attributs
3.3.1.3 - Exemples
3.3.1.1 - Modèle de contenu
3.3.1.2 - Attributs
3.3.1.3 - Exemples

L'élément <scope> consiste en un ou plusieurs éléments <topicRef>, <resourceRef> ou <subjectIndicatorRef>. L'union des sujets correspondant à ces éléments spécifie le domaine de validité dans lequel les caractéristiques associées au topique sont valides.

Une déclaration de caractéristique de topique n’est valide que dans les limites d’une certaine portée. Quand la déclaration d’une caractéristique de topique ne spécifie aucune portée, alors cette caractéristique est valide dans la portée non-contrainte.

Apparaît dans : <baseName>, <occurrence>, <association>.

<!ELEMENT scope  ( topicRef  | resourceRef | subjectIndicatorRef )+ >
<topicRef>

Élément enfant répétable qui référence un élément <topic> dont le sujet contribue à la définition du domaine de validité.

<resourceRef>

Élément enfant répétable qui référence une ressource qui contribue à définir le domaine de validité.

<subjectIndicatorRef>

Élément enfant répétable qui référence une ressource indiquant l'identité du sujet qui contribue à définir le domaine de validité.

<!ATTLIST scope
     id              ID        #IMPLIED
  >

L'élément <scope> possède l'attribut suivant :

id

Identificateur unique de l'élément.

Définition d'un domaine de validité consistant en un sujet English utilisant un sujet publié :

  <scope>
    <subjectIndicatorRef
      xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>
  </scope>

Définition d'un domaine de validité constitué des topiques tragedy et theatre du document courant :

  <scope>
    <topicRef xlink:href="#tragedy"/>
    <topicRef xlink:href="#theatre"/>
  </scope>

Pour plus d'exemples, voir l’élément <baseName>.

3.4. Classes et instances

3.4.1 - L'élément <instanceOf>
3.4.2 - Modèle de contenu
3.4.3 - Attributs
3.4.4 - Exemples

L'élément <instanceOf> définit la classe à laquelle appartient son parent au travers de l’un de ses deux éléments enfant possibles : <topicRef> et <subjectIndicatorRef>.

Pour les contraintes d'utilisation de <instanceOf>, référez-vous à aux descriptions des éléments types qui peuvent être ses parents, à savoir <topic> (voir Section 2.2.1), <occurrence> (voir Section 2.2.3) et <association> (voir Section 2.3).

L'élément <instanceOf> est un raccourci syntaxique pour une association d’un type spécial défini par le sujet publié classe-instance (voir ???).

Apparaît dans : <topic> (voir Section 2.2.1), <occurence> (voir Section 2.2.3), et <association> (voir Section 2.3).

<!ELEMENT instanceOf  ( topicRef | subjectIndicatorRef ) >
<topicRef>

Élément enfant qui référence un élément <topic> qui réifie une classe de sujet.

<subjectIndicatorRef>

Élément enfant qui référence une ressource indiquant l'identité d'une classe de sujet.

<!ATTLIST instanceOf
     id              ID        #IMPLIED
  >

L'élément <instanceOf> possède l'attribut suivant :

id

Identificateur unique de l'élément.

Dans l’exemple suivant on déclare que le topique ayant l'id « hamlet » est une instance du topique type dont l'id « play » :

 <topic id="play">
    ...
  </topic>

  <topic id="hamlet">
    <instanceOf>
      <topicRef xlink:href="#play"/>
    </instanceOf>
  </topic>

Dans l’exemple suivant, on référence l’indicateur de sujet dont le topique est une instance :

<topic id="hamlet">
    <instanceOf>
      <subjectIndicatorRef
          xlink:href="http://www.shakespeare.org/plays.html"/>
    </instanceOf>
  </topic>

Dans l’exemple suivant, on référence le sujet publié d’une onthologie publique dont le topique est une instance :

<topic id="shakespeare">
    <instanceOf>
      <subjectIndicatorRef
          xlink:href="http://www.iptc.org/NewsML/topicsets/-
          topicset.iptc-topictype.xml#TopicTypes.Person"/>
    </instanceOf>
  </topic>

Pour plus d'exemples, voir <topic> (voir Section 2.2.1), <occurence> (voir Section 2.2.3), et <association> (voir Section 2.3).

3.5. La Topic Map

3.5.1 - L'élément <topicMap>
3.5.2 - Modèle de contenu
3.5.3 - Attributs
3.5.4 - Exemples

L'élément <topicMap> est le parent de tous les éléments <topic>, <association> et <mergeMap> d’un document de type Topic Map.

L'élément <topicMap> est la racine à partir de laquelle commence la reconnaissance syntaxique des Topic MapTopic Maps. L'élément <topicMap> peut être la racine d'un document ne contenant qu'un élément <topicMap> à sa racine, ou la début de la sous-branche d'un document XML plus large contenant autre chose que la seule carte de sujets. Dans ce cas, seul le sous-arbre commençant par l'élément <topicMap> sera pris en compte pour la reconnaissance syntaxique et la vérification de conformité.

 <!ELEMENT topicMap
     ( topic | association | mergeMap )*
  >
<topic>

Élément enfant optionnel et répétable qui réifie un seul sujet.

<association>

Élément enfant optionnel et répétable qui spécifie une relation entre topiques.

<mergeMap>

Élément enfant optionnel et répétable qui provoque la fusion de la Topic Map avec une autre.

  <!ATTLIST topicMap
     id              ID        #IMPLIED
     xmlns           CDATA     #FIXED 'http://www.topicmaps.org/xtm/1.0/'
     xmlns:xlink     CDATA     #FIXED 'http://www.w3.org/1999/xlink'
     xml:base        CDATA     #IMPLIED
  >

L'élément <topicMap> possède les attributs suivants :

id

Identificateur unique de l'élément.

xmlns

Identificateur de l'espace de nom XML par défaut.

xmlns:xlink

Identificateur de l'espace de nom de XLink.

xml:base

Référence à l'URI de base du document.

Voir les sections 5.2 et 5.4 de [XLink] pour les questions relatives à l’utilisation et la conformité, ainsi que la section 3 de [XMLBase] pour des détails sur l'attribut xml:base.

Un élément <topicmap> intégré dans un document XML :

...
<topicMap>

<!-- mettre ici les déclarations de topiques, d’association et de fusion -->

</topicMap>
  ...

Un élément <topicmap> racine d'un document complet :

<?xml version="1.0"?>
<!DOCTYPE topicMap
         PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN"
                "file://usr/local/home/gromit/xml/xtm/xtm1.dtd">
<topicMap xmlns='http://www.topicmaps.org/xtm/1.0/'
         xmlns:xlink='http://www.w3.org/1999/xlink'
         xml:base='http://www.shakespeare.org/hamlet/'>

  <!-- mettre ici les déclarations de topiques, d’association et de fusion -->

</topicMap>

3.6. Topiques et sujets

3.6.1 - L'élément <topic>
3.6.1.1 - Modèle de contenu
3.6.1.2 - Attributs
3.6.1.3 - Exemples
3.6.2 - L'élément <subjectIdentity>
3.6.2.1 - Modèle de contenu
3.6.2.2 - Attributs
3.6.2.3 - Exemples
3.6.1.1 - Modèle de contenu
3.6.1.2 - Attributs
3.6.1.3 - Exemples

L'élément <topic> spécifie les caractéristiques nom et occurrence d'un topique. Il possède un identificateur et permet de déclarer la ou les classes qu’il instancie ainsi que l'identité du sujet qu'il réifie.

Par définition, un topique ne réifie qu'un seul sujet. Les topiques ont été conçus pour n’adresser exactement qu’un seul sujet, même si ce dernier est défini implicitement. Pendant un traitement XTM, les topiques ayant le même sujet seront fusionnés, cela en fonction des règles définies en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).

Toutefois, un document de type Topic Map peut contenir plusieurs topiques réifiant le même sujet (pour de plus amples discussions sur le processus de fusion, voir Section 3.10).

La classe dont le topique est une instance est définie par l’élément enfant <instanceOf>, qui adresse soit un topique, soit un indicateur de sujet. S'il n'y a pas d'élément enfant <instanceOf>, la classe par défaut est celle définit par le sujet publié topique.

Un élément <topic> spécifie zéro ou plusieurs noms et occurrences pertinents pour son sujet. Les occurrences sont spécifiées au moyen des éléments enfants <occurrence>.

Apparaît dans : <topicMap>

<!ELEMENT topic
     ( instanceOf*, subjectIdentity?, ( baseName | occurrence )* )
  >
<instanceOf>

Élément enfant optionel et répétable qui permet de spécifier une classe dont le topique est une instance.

<subjectIdentity>

Élément enfant optionnel qui spécifie l'identité du sujet.

<baseName>

Élément enfant optionnel et répétable qui spécifie une caractéristique de nom pour ce topique.

<occurence>

Élément enfant optionnel et répétable qui spécifie les ressources d'information pertinentes pour ce topique.

<!ATTLIST topic
     id              ID        #REQUIRED
  >

L'élément <topic> possède l'attribut suivant :

id

Identificateur unique de l'élément.

Dans l’exemple suivant, le topique dont l'id est « hamlet » est une instance du topique type dont l'id est « play » :

<topic id="hamlet">
  <instanceOf>
    <topicRef xlink:href="#play"/>
	</instanceOf>
	<!-- écrire ici les noms de base et les occurrences -->
  </topic>

Pour plus d'exemples, voir les éléments <subjectIdentity>, <baseName>, <variant>, <association>, et <occurrence>.

3.6.2.1 - Modèle de contenu
3.6.2.2 - Attributs
3.6.2.3 - Exemples

L'élément <subjectIdentity> sert à spécifier le sujet réifié par un topique, cela via ses éléments enfants <resourceRef>, <subjectIndicatorRef> et/ou <topicRef>.

Lorsque le sujet du topique est adressable, il est indiqué directement par l'élément <resourceRef>. La ressource elle-même est alors considérée comme étant le sujet, et non ce qu’elle indique ou veut dire. Il ne peut y avoir qu'une seule ressource de ce type par topique.

Par opposition aux sujets, les ressources peuvent aussi être des indicateurs de sujets. Les ressources sont utilisées pour indiquer des sujets via l'utilisation de l'élément <subjectIndicatorRef>, par lequel il peut y avoir plus d'un sujet par topique.

Un topique peut aussi indiquer qu'il possède le même sujet qu'un autre topique, cela en référençant ce dernier via l'élément <topicRef>. Il peut y avoir plus d'un élément comme celui-là impliquant par la suite des mécanismes de fusions.

Apparaît dans : <topic>.

  <!ELEMENT subjectIdentity
     ( resourceRef?, ( topicRef | subjectIndicatorRef )* )
  >
<resourceRef>

Élément optionnel qui permet de référençer un sujet adressable.

<topicRef>

Élément enfant optionnel et répétable qui référence un élément topique avec lequel il partage un même sujet.

<subjectIndicatorRef>

Élément enfant optionnel et répétable qui référençe un indicateur de sujet.

  <!ATTLIST subjectIdentity
     id              ID        #IMPLIED
  >

L'élément <subjectIdentity> possède l'attribut suivant :

id

Identificateur unique de l'élément.

L’exemple suivant établit l'identité d’un topique en référençant un indicateur de sujet publié, en l’occurrence le pays Denmark conformément à ce qui est défini par TopicMaps.Org pour les PSI basés sur l’ISO 3166 :

  <topic id="dk">
    <subjectIdentity>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/country.xtm#dk"/>
    </subjectIdentity>
  </topic>

L’exemple suivant établit l'identité d’un topique en référençant une ontologie de manière un peu plus informelle (ici, la version en ligne du livre CIA World Factbook) :

  <topic id="da">
    <subjectIdentity>
      <subjectIndicatorRef
        xlink:href="http://www.cia.gov/cia/publications/factbook/geos/da.html"/>
    </subjectIdentity>
  </topic>

Dans l’exemple suivant, le topique établit une correspondance entre les ontologies ISO et CIA, et en formant ainsi une fusion correcte :

  <topic id="denmark">
    <subjectIdentity>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/country.xtm#dk"/>
      <subjectIndicatorRef
        xlink:href="http://www.cia.gov/cia/publications/factbook/geos/da.html"/>
    </subjectIdentity>
  </topic>

3.7. Noms de topiques

3.7.1 - L'élément <baseName>
3.7.1.1 - Modèle de contenu
3.7.1.2 - Attributs
3.7.1.3 - Exemples
3.7.2 - L'élément <baseNameString>
3.7.2.1 - Modèle de contenu
3.7.2.2 - Attributs
3.7.2.3 - Exemples
3.7.3 - L'élément <variant>
3.7.3.1 - Modèle de contenu
3.7.3.2 - Attributs
3.7.3.3 - Exemples
3.7.4 - L'élément <variantName>
3.7.4.1 - Modèle de contenu
3.7.4.2 - Attributs
3.7.4.3 - Exemples
3.7.5 - L'élément <parameters>
3.7.5.1 - Modèle de contenu
3.7.5.2 - Attributs
3.7.5.3 - Exemples
3.7.1.1 - Modèle de contenu
3.7.1.2 - Attributs
3.7.1.3 - Exemples

L'élément <baseName> sert à spécifier le nom de base d’un topique. Le nom d’un topique est une chaîne de caractère contenue dans l'élément <baseNameString>, enfant de <baseName>. Le domaine de validité de validité de l’affectation de ce nom peut être précisé en utilisaant l'élément enfant <scope>. Si aucun domaine de validité n'est ainsi précisée, le domaine de validité n'est pas contraint et le nom est toujours valide. Un topique peut posséder plusieurs noms de base valables pour un ou plusieurs domaines de validité.

Des différences peuvent être notées en langage naturel entre les noms de base des topiques. Il faut pour cela utiliser l'élément enfant <scope>. Des sujets publiés adaptés à la définition de domaines de validité sont disponibles dans XTM Language Topics, une Topic Map pour langages naturels maintenue par TopicMap.org (voir Annexe E. Noyau des indicateurs de sujets publiés de XTM 1.0 (normatif)).

Les noms de base doivent suivre les contraintes de nommage des topiques. Deux topiques ayant le même nom dans le même domaine de validité réifient le même sujet et devraient, de ce fait, être fusionnés.

Des formes alternatives du nom de base du topique peuvent être spécifiées par l’élément <variant>, elles servent aux traitements informatiques particuliers comme le tri, la recherche et l'affichage.

Apparaît dans : <topic>.

<!ELEMENT baseName ( scope?, baseNameString, variant* )>
<scope>

Élément enfant optionel qui permet de spécifier le domaine de validité dans lequel le nom de base est valide.

<baseNameString>

Élément enfant obligatoire qui contient la chaîne de caractères représentant le nom de base du topique.

<variant>

Élément enfant optionnel et répétable qui permet de définir des formes alternatives du nom de base.

  <!ATTLIST baseName
     id              ID        #IMPLIED
  >

L'élément <baseName> possède l'attribut suivant :

id

Identificateur unique de l'élément.

Exemple simple.

  <topic id="shakespeare">
    <baseName>
      <baseNameString>William Shakespeare</baseNameString>
    </baseName>
  </topic>

Dans l’exemple suivant, le topique a des noms multiples dans différentes langues, différentiés par un domaine de validité (on suppose qu'il existe des topiques dont les id sont « en » et « da » réifiant respectivement les sujets « English » et « Danish ».

  <topic id="denmark">
    <!-- baseName for English -->
    <baseName>
      <scope><topicRef xlink:href="#en"/></scope>
      <baseNameString>Denmark</baseNameString>
    </baseName>
    <!-- baseName for Danish -->
    <baseName>
      <scope><topicRef xlink:href="#da"/></scope>
      <baseNameString>Danmark</baseNameString>
    </baseName>
  </topic>

Dans l’exemple suivant, on utilise un domaine de validité pour éviter une fusion indésirable qui seraient sinon consécutive aux règles de nommage des topiques (sans la notion de domaine de validité, les deux topiques utilisant le nom « Hamlet » seraient fusionnés).

  <topic id="hamlet">
    <baseName>
      <baseNameString>The Tragedy of Hamlet, Prince of
        Denmark</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#play"/></scope>
      <baseNameString>Hamlet</baseNameString>
    </baseName>
  </topic>

  <topic id="character-hamlet">
    <baseName>
      <scope><topicRef xlink:href="#character"/></scope>
      <baseNameString>Hamlet</baseNameString>
    </baseName>
  </topic>

Dans l’exemple suivant, on donne plusieurs noms à un type d'association afin d’y faire référence de différentes manières. Cela en fonction de leur rôle. Dans cet exemple, le topique a comme nom par défaut « written by » (dans un domaine de validité non contraint) et « author » dans le domaine de validité « author », ce qui a été jugé plus pertinent.

  <topic id="written-by">
    <baseName>
      <baseNameString>written by</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#author"/></scope>
      <baseNameString>author of</baseNameString>
    </baseName>
  </topic>
3.7.2.1 - Modèle de contenu
3.7.2.2 - Attributs
3.7.2.3 - Exemples

L'élément <baseNameString> permet de spécifies le nom de base du topique défini par son ancêtre <topic>.

Apparaît dans : <baseName>.

<!ELEMENT baseNameString (#PCDATA)>

Cet élément ne contient que des données de type caractères (et donc aucun sous-élément).

  <!ATTLIST baseNameString
     id              ID        #IMPLIED
  >

L'élément <baseNameString> possède l'attribut suivant :

id

Identificateur unique de l'élément.

Voir l'exemple de l'élément <baseName> (voir Section 3.7.1).

3.7.3.1 - Modèle de contenu
3.7.3.2 - Attributs
3.7.3.3 - Exemples

L'élément <variant> permet de spécifier une forme alternative du nom de base d’un topique, cela afin de pouvoir lui appliquer un traitement informatique particulier. Celui-là est précisé dans l'élément enfant <parameters>. Ces cas particuliers de traitements sont, entre autres, le tri et l'affichage.

Les éléments enfants <variantName>, qui peuvent apparaître de manière récursive, fournissent autant de formes alternatives du nom de base. Le domaine de validité de traitement approprié à une variante du nom de base est défini par l'union des paramètres des niveaux courant supérieurs de cette structure récursive. En d'autres termes, les paramètres s’héritent quand on s’enfonce dans l’arbre. Pour une description plus complète, voir les traitements de domaines de validité de variants en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).

Une variante de nom dont les paramètres incluent les sujets publiés « display » ou « sort » (voir