XML Topic Maps (XTM 1.0)

Spécification de TopicMaps.Org

Traduction française

Historique des versions
Version 1.0	16/07/2003	Alain Herbuel
Rédaction première version de cette traduction. Création des CSS. Il faut bien commencer un jour !
Version 2.0	01/09/2003	Alain Herbuel
Relecture et corrections, amélioration des CSS.
Version 3.0	09/09/2003	Jean-Jacques Thomasson
Relecture et corrections.
Version 4.0	21/09/2003	Alain Herbuel
Fusion des versions, retouche ponctuation et mise en forme, formatage des exemples.
Version 4.1	14/11/2003	Alain Herbuel
Prise en compte des remontées de nos lecteurs (merci à eux) : fautes de français, de traduction, de frappe. erreurs dans la fabrication de certains liens. Ajustement de la feuille de style pour faciliter la lecture.

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 - Occurrence

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 - Principe 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 nommage 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ée des 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 spécification 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 international 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 Web afin 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 :

XTM doit être simple d'utilisation sur Internet.
XTM doit supporter une grande variété d'applications.
XTM doit être compatible avec XML, XLink, et ISO 13250.
Il doit être facile d'écrire des programmes traitant des documents XTM.
Le nombre de fonctionnalités optionnelles dans XTM doit être réduit au strict minimum, idéalement zéro.
Les documents XTM doivent être lisibles et clairs dans la mesure du possible.
La conception de XTM doit être faite rapidement.
La conception de XTM doit être formelle et concise.
Les documents XTM doivent être faciles à créer.

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

Un élément <association>.
Une relation entre topiques établie par l’élément <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

Un élément enfant (<baseName>) d'un élément <topic>.
La caractéristique nom d’un topique fournie par le contenu de l’élément <baseNameString>. Les noms de base doivent être uniques dans un même domaine de validité (voir contraintes de nommage des topiques).

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

Un élément enfant (<member>) d'un élément <association>.
Un ensemble de topiques jouant un rôle particulier dans une association.

Fusion

Processus de fusion de deux Topic Maps, soit en tant que résultat de directives explicites <merge>, soit pour répondre aux besoins de mise en œuvre particulières.
Processus de fusion de deux topiques.

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

Un élément enfant (<occurrence> d'un élément <topic>.
Une occurrence de topique.

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

Un élément enfant (<parameters> d'un élément <variant>.
Information, sous la forme d’un ensemble de topiques, exprimant le domaine de validité de traitement approprié d’une variante de nom.

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’autres 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

Etendue de la validité d’une affectation de caractéristique de Topique. Domaine de validité dans lequel un nom ou une occurrence est affecté à un topique donné et domaine de validité dans lequel les topiques sont mis en relation au sein des associations.
Ensemble de topiques spécifié via un élément <scope>.

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

Tout ce qui peut être discuté ou conçu par un humain. De manière plus générique, un sujet est n’importe quoi, que cela existe réellement ou non ou ait de quelconques particularités, et à propos duquel on peut dire quelque chose, indépendamment du sens qu’on lui donne.
Toute chose pour laquelle l’auteur d’une Topic Map a décidé de discourir.
Toute chose réifiée par un topique dans une Topic Map ; le principe d’organisation d’un topique. En dernier recours, ce sont les humains qui peuvent décider des sujets des topiques.

Voire aussi identité de sujet, indicateur de sujet .

Identité de sujet

Élément <subjectIdentity> enfant d’un élément <topic>.
Ce qui fait que deux sujets sont identiques différents. La détermination d’identité de sujet est facilitée, voire automatisée, en utilisant les indicateurs de sujets publiés
Un critère de fusion de Topic Maps comme définie en (voir Annexe F. Spécification des traitements de documents XTM (informatif)).

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ères d’indiquer l’identité d’un sujet dans une carte de topique :

En utilisant l’élément <topicRef> et pointant vers un élément <topic> ayant le même sujet.
En utilisant l’élément <subjectIndicatorRef> pour pointer vers une ressource qui indique le sujet.
En utilisant l’élément <resourceRef> pour pointer vers une ressource qui est le sujet.

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 :

un nom de topique,
une occurrence de topique, ou
un rôle joué par un topique dans une association.

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

Une collection de topiques, d’associations, et de domaines de validité qui peuvent exister sous une des formes suivantes :
- Un format d’échange sérialisé (e.g. un document type Topic Map exprimé sous la forme de la syntaxe XTM).
- Une forme interne à une application, respectant les caractéristiques de traitement définies en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).
L’élément racine <topicmap> d’un document de type Topic Map exprimé en fonction de la syntaxe XTM.

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

La caractéristique « nom de base » d’un topique (incluant les variantes de noms de ce nom de base).
De manière informelle : La chaîne de caractères définie comme étant le nom d’un topique via l’utilisation de l’élément <basenameString>.

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 :

accessible via un URI alors spécifié en utilisant l’élément <resourceRef>,
être mise en ligne en utilisant l’élément <resourceData>.

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 contrainte 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éifie »). 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 paternité.

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 milliers 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’images ou 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 rapidement 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 ressource, 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 substitut qui 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>

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 naturel 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 :

un jeu de topiques dont chacun est un substitut d’un sujet (il le réifie), et peut avoir un ou plusieurs noms ;
des liens entre les topiques et les ressources d'informations qui sont les occurrences des sujets réifiés par les topiques (des exemples sont « traité dans », « mentionné dans », « représenté dans », etc.) ;
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 conséquence, les sujets eux-mêmes ne sont pas apparents dans la description 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 multimédia, s’applique à de nombreux autres cas de figure (ou qui semblent) très éloignés des seuls préoccupations d’indexation des encyclopédies. La terminologie continue de nos jours à refléter les origines historiques des termes pour des besoins de clarification et de concrétisation.

Vous noterez que les ressources informatiques quelles qu’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. 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é

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éification 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).

2.2.1.1. Sujet

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 peuvent 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.

2.2.1.2. Réification

L'acte de création d’un topique est appelé réification. Une chose réifiée 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.

2.2.1.3. Identité de sujet

L’identification d’un sujet est 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 :

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

2.2.1.4. Indicateur de sujet

Un indicateur de sujet est une ressource dont l’auteur d’une carte de topique pense qu’elle est une identification non ambiguë 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.

2.2.1.5. Caractéristique de topique

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 :

un nom (voir Section 2.2.2),
une occurrence (voir Section 2.2.3),
un rôle (voir Section 2.3.2).

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

2.2.1.6. Domaine de validité

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. Nom

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.

2.2.3. Occurrence

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. soit est référençable via un URI (une « ressource de type référence »),
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

2.3.1. Membre

Une association 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éfini 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 nommage, non de direction de celle-là.

2.3.2. Rôle

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

2.3.3. Classe - instance

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 », 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).

2.3.4. Superclasse - sous-classe

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.

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. un format d'échange sérialisé (e.g. un document de type Topic Map exprimé en XTM ou dans une autre syntaxe) ;
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.

2.4.1. Noeud d'une Topic Map

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).

2.4.2. Topic Map cohérente

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)).

2.4.3. Document de type Topic Map

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.

2.4.4. Document XTM

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

2.5.1. Introduction

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.

2.5.2. Indicateurs XTM obligatoire de sujets publiés

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 :

La fusion de deux Topic Maps, provoquée par un ordre explicite <mergeMap> ou par des raisons propres à une application.
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 :

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.
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 :

ils ont un ou plusieurs indicateurs de sujets commun ;
ils réifient le même sujet adressable ;
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. L'élément <topicRef>

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>

3.2.1.1. Modèle de contenu

<!ELEMENT topicRef  EMPTY >

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

3.2.1.2. Attributs

  <!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é.

3.2.1.3. Exemple

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. Elément <subjectIndicatorRef>

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>.

3.2.2.1. Modèle de contenu

<!ELEMENT subjectIndicatorRef  EMPTY >

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

3.2.2.2. Attributs

<!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é.

3.2.2.3. Exemples

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. L'élément <scope>

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>.

3.3.1.1. Modèle de contenu

<!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é.

3.3.1.2. Attributs

<!ATTLIST scope
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.3.1.3. Exemples

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

3.4.1. L'élément <instanceOf>

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).

3.4.2. Modèle de contenu

<!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.

3.4.3. Attributs

<!ATTLIST instanceOf
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.4.4. Exemples

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 ontologie 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

3.5.1. L'élément <topicMap>

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 le 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é.

3.5.2. Modèle de contenu

 <!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.

3.5.3. Attributs

  <!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.

3.5.4. Exemples

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. L'élément <topic>

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>

3.6.1.1. Modèle de contenu

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

<instanceOf>: Élément enfant optionnel 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.

3.6.1.2. Attributs

<!ATTLIST topic
     id              ID        #REQUIRED
  >

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

id: Identificateur unique de l'élément.

3.6.1.3. Exemples

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. L'élément <subjectIdentity>

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>.

3.6.2.1. Modèle de contenu

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

<resourceRef>: Élément optionnel qui permet de référencer 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érence un indicateur de sujet.

3.6.2.2. Attributs

  <!ATTLIST subjectIdentity
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.6.2.3. Exemples

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. L'élément <baseName>

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é, 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>.

3.7.1.1. Modèle de contenu

<!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.

3.7.1.2. Attributs

  <!ATTLIST baseName
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.7.1.3. Exemples

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. L'élément <baseNameString>

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>.

3.7.2.1. Modèle de contenu

<!ELEMENT baseNameString (#PCDATA)>

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

3.7.2.2. Attributs

  <!ATTLIST baseNameString
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.7.2.3. Exemples

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

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

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 Section 2.5.2) est sémantiquement équivalente à l'affichage et au tri des noms tels que définis dans l'ISO 13250.

Apparaît dans : <baseName>.

3.7.3.1. Modèle de contenu

<!ELEMENT variant  ( parameters, variantName?, variant* ) >

<parameters>: Élément enfant unique et obligatoire qui permet de spécifier un domaine de validité de traitement additionnel pour son parent <variant>.
<variantName>: Élément enfant optionnel qui permet de spécifier une forme alternative au nom de base.
<variant>: Élément enfant optionnel et répétable qui permet de spécifier des paramètres additionnels et des noms différents à l’intérieur du domaine de validité définit par l'élément parent <variant>.

3.7.3.2. Attributs

  <!ATTLIST baseNameString
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.7.3.3. Exemples

Dans l’exemple suivant, on spécifie une variante du nom de base afin d'effectuer un tri.

  <topic id="shakespeare">
    <baseName>
      <baseNameString>William Shakespeare</baseNameString>
      <!-- form for sorting (sort name) -->
      <variant>
        <parameters><topicRef xlink:href="#sort"/></parameters>
        <variantName>
          <resourceData>shakespeare,william</resourceData>
        </variantName>
      </variant>
    </baseName>
  </topic>

  ...

  <topic id="sort">
    <subjectIdentity>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#psi-sort"/>
    </subjectIdentity>
  </topic>

L'exemple suivant montre différentes variantes du nom de base « Hamlet » utilisées pour des affichages écran ou des synthèses vocales. Dans le cas de l'affichage (« display »), le sous-arbre est une arborescence d’éléments <variant> qui montre comment les paramètres sont de plus en plus pertinents au fur et à mesure que l’on s’enfonce dans l'arbre.

  <topic id="hamlet">
    <baseName>
      <baseNameString>Hamlet</baseNameString>

      <!-- alternative forms for display (display name) -->
      <variant>
        <parameters><topicRef xlink:href="#display"/></parameters>

        <!-- variant subtree for icon -->
        <variant>
          <parameters><topicRef xlink:href="#icon"/></parameters>
          <!-- variant subtree for large -->
          <variant>
            <parameters><topicRef xlink:href="#large"/></parameters>
            <variantName>
              <!-- effective parameters = display + icon + large -->
              <resourceRef xlink:href="img/hamlet64x64.png" />
            </variantName>
          </variant>
          <!-- variant subtree for small -->
          <variant>
            <parameters><topicRef xlink:href="#small"/></parameters>
            <variantName>
              <!-- effective parameters = display + icon + small -->
              <resourceRef xlink:href="img/hamlet16x16.png" />
            </variantName>
          </variant>
        </variant>

        <!-- variant subtree for full screen -->
        <variant>
          <parameters><topicRef xlink:href="#full-screen"/></parameters>
          <!-- variant subtree for VGA -->
          <variant>
            <parameters><topicRef xlink:href="#vga"/></parameters>
            <variantName>
              <!-- effective parameters = display + full-screen + vga -->
              <resourceRef xlink:href="img/hamlet640x480.png" />
            </variantName>
          </variant>
          <!-- variant subtree for SVGA -->
          <variant>
            <parameters><topicRef xlink:href="#svga"/></parameters>
            <variantName>
              <!-- effective parameters = display + full-screen + svga -->
              <resourceRef xlink:href="img/hamlet800x600.png" />
            </variantName>
          </variant>
        </variant>

      </variant>

      <!-- alternative form for audible delivery -->
      <variant>
        <parameters><topicRef xlink:href="#audible"/></parameters>
        <variantName>
              <!-- effective parameters = audible -->
          <resourceRef xlink:href="au/hamlet.au"/>
        </variantName>
      </variant>

    </baseName>
  </topic>

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

L'élément <variantName> fournit la ressource utilisée comme variante du nom de base. Elle peut être référencée en utilisant l’élément <resourceRef> ou être directement inclue en utilisant alors l’élément <resourceData>.

Apparaît dans : <variant>.

3.7.4.1. Modèle de contenu

<!ELEMENT variantName  ( resourceRef | resourceData ) >

<resourceRef>: Élément enfant qui référence une ressource fournissant une variante de nom.
<resourceData>: Élément enfant contenant la ressource fournissant la variante de nom.

3.7.4.2. Attributs

  <!ATTLIST variantName
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.7.4.3. Exemples

Voir les exemples de l'élément <variant> (voir Section 3.7.3).

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

L'élément <parameters> contient un ou plusieurs éléments <topicRef> et <subjectIndicatorRef>. L'union des sujets correspondants permet de définir un domaine de validité de traitement additionnel dans lequel les variantes de noms définie dans le sous-arbre sont considérées comme étant pertinentes.

Apparaît dans : <variant>.

3.7.5.1. Modèle de contenu

<!ELEMENT parameters  ( topicRef | subjectIndicatorRef )+ >

<topicRef>: Élément enfant répétable qui référence un topique indiquant le domaine de validité de traitement de l'élément parent <variant>.
<subjectIndicatorRef>: Élément répétable qui référence une ressource indiquant le domaine de validité de traitement de l'élément parent <variant>.

3.7.5.2. Attributs

  <!ATTLIST parameters
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.7.5.3. Exemples

Se rapporter aux exemples de l'élément <variant> (voir Section 3.7.3).

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.8.1. L'élément <association>

3.8.1.1 - Modèle de contenu
3.8.1.2 - Attributs
3.8.1.3 - Exemples

L'élément <association> crée une relation entre les topiques membres d’une association. Les topiques ont ainsi des rôles pour cette association.

La classe d’une association est spécifiée par l'élément enfant <instanceOf>. A défaut, l'association appartient à la classe du sujet publié association.

Le domaine de validité de validité d’une association peut être exprimé par l'élément enfant <scope>. A défaut, le domaine de validité est non-contraint et l'association toujours valide.

Apparaît dans : <topicMap>.

3.8.1.1. Modèle de contenu

  <!ELEMENT association
     ( instanceOf?, scope?, member+ )
  >

<instanceOf>: Élément enfant optionnel qui spécifie la classe d’appartenance de l'association.
<scope>: Élément enfant optionnel qui spécifie le domaine de validité de l'association.
<member>: Élément obligatoire et répétable qui définit les topiques jouant un rôle dans l’association.

3.8.1.2. Attributs

  <!ATTLIST association
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.8.1.3. Exemples

Dans l’exemple suivant, on établit une association du type « written-by » entre le topique « shakespeare » (jouant le rôle de « author »), et le topic « hamlet » (jouant le rôle de « work »). En d'autres termes, [the work] Hamlet a été écrit par [the author] Shakespeare (ou [the author] Shakespeare a écrit [the work] Hamlet).

  <association id="will-wrote-hamlet">
    <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>

L’exemple suivant est la réification d’une association afin de pouvoir lui affecter des caractéristiques.

  <topic id="will-wrote-hamlet-topic">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="#will-wrote-hamlet"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Shakespeare's authorship of
        Hamlet</baseNameString>
    </baseName>
    <!-- occurrences may go here -->
  </topic>

Dans l’exemple qui suit, on déclare une relation de type classe / instance entre « hamlet » et « play » en utilisant une association au lieu d’utiliser l'élément <instanceOf>. Ce qui est sémantiquement équivalent à l'exemple précédent.

  <association>
    <instanceOf>
      <subjectIndicatorRef
        xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#class-instance"/>
    </instanceOf>
    <member>
      <roleSpec>
        <subjectIndicatorRef
          xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#class"/>
      </roleSpec>
      <topicRef xlink:href="#play"/>
    </member>
    <member>
      <roleSpec>
        <subjectIndicatorRef
          xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#instance"/>
      </roleSpec>
      <topicRef xlink:href="#hamlet"/>
    </member>
  </association>

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

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

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

L'élément <member> définit les topiques jouant un rôle dans une association. L'élément <roleSpec> spécifie le rôle joué par ce topique.

Apparaît dans : <association>.

3.8.2.1. Modèle de contenu

  <!ELEMENT member
     ( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )+ )
  >

<roleSpec>: Élément enfant optionnel qui précise le rôle joué par le membre dans l'association.
<topicRef>: Élément enfant répétable qui référence le topique jouant le rôle spécifié.
<resourceRef>: Élément enfant répétable qui référence la ressource jouant le rôle spécifié.
<subjectIndicatorRef>: élément enfant répétable qui référence l’indicateur de sujet du sujet jouant le rôle spécifié.

3.8.2.2. Attributs

  <!ATTLIST member
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.8.2.3. Exemples

Se rapporter aux exemples de l'élément <association> (voir Section 3.8.1).

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

L'élément <roleSpec> spécifie le rôle joué par un membre d'une association.

Apparaît dans : <member>.

3.8.3.1. Modèle de contenu

<!ELEMENT roleSpec  ( topicRef | subjectIndicatorRef ) >

<topicRef>: Élément enfant qui référence un topique réifiant un rôle dans une association.
<subjectIndicatorRef>: Élément enfant qui référence un indicateur de sujet servantde rôle dans pour l’association.

3.8.3.2. Attributs

  <!ATTLIST roleSpec
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.8.3.3. Exemples

Se rapporter aux exemples de l'élément <association> (voir Section 3.8.1).

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.9.1. L'élément <occurence>

3.9.1.1 - Modèle de contenu
3.9.1.2 - Attributs
3.9.1.3 - Exemples

L'élément <occurrence> référence une ressource contenant des informations pertinentes relatives au le topique.

La classe d’appartenance de l’occurence est spécifiée par l'élément enfant <instanceOf>. A défaut, elle est celle définie par le sujet publié occurrence.

Le domaine de validité d’une occurrence peut être définit en utilisant l'élément enfant <scope>. A défaut, le domaine est libre et l’occurrence est toujours valide.

Apparaît dans : <topic>.

3.9.1.1. Modèle de contenu

   <!ELEMENT occurrence
     ( instanceOf?, scope?, ( resourceRef | resourceData ) )
  >

<instanceOf>: Élément enfant optionnel qui spécifie la classe d’appartenance de l'occurrence.
<scope>: Élément optionnel qui spécifie le domaine de validité de l’occurrence.
<resourceRef>: Élément enfant qui référence la ressource qui sert d’occurrence au topique.
<resourceData>: Élément enfant contenant directement la ressource qui sert d’occurrence au topique.

3.9.1.2. Attributs

  <!ATTLIST occurence
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.9.1.3. Exemples

Dans l’exemple suivant, le topique dont l'id est « hamlet » possède une occurrence de type « date-of-composition » composée de la chaîne « 1600-01 » et une occurrence de type « xml-version » qui se trouve à l'URL donnée.

  <topic id="hamlet">
    <occurrence>
      <instanceOf>
        <topicRef xlink:href="#date-of-composition"/>
      </instanceOf>
      <resourceData>1600-01</resourceData>
    </occurrence>
    <occurrence id="hamlet-in-xml">
      <instanceOf>
        <topicRef xlink:href="#xml-version"/>
      </instanceOf>
      <resourceRef
        xlink:href="http://www.csclub.uwaterloo.ca/u/relander/XML/hamlet.xml"/>
    </occurrence>
  </topic>

Réification d'une des occurrences précédente afin de lui affecter des caractéristiques.

  <topic id="hamlet-in-xml-topic">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="#hamlet-in-xml"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Jon Bosak's XML version of
        Hamlet</baseNameString>
    </baseName>
    <!-- occurrences may go here (e.g. commentaries
         on the XML version of Hamlet)-->
  </topic>

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

L'élément <resourceRef> référence une ressource par son URI.

Les ressources peuvent être référencées pour l'une des trois raisons suivantes :

en tant qu'occurrence d’un topique (dans un élément <occurrence>) ;
en tant que sujet adressable (dans les éléments <member>, <mergeMap>, <scope>, et <subjectIdentity>) ;
en tant que variante de nom de topique (dans les éléments <variantName>).

Apparaît dans : <member>, <mergeMap>, <occurrence>, <scope>, <subjectIdentity>, et <variantName>.

3.9.2.1. Modèle de contenu

<!ELEMENT resourceRef  EMPTY >

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

3.9.2.2. Attributs

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

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

id: Identificateur unique de l'élément.
xlink:type: Identifie le lien comme étant un lien XLink de type simple.
xlink:href: Fournit la référence de cette ressource sous la forme d’un URI.

3.9.2.3. Exemples

Se rapporter aux exemples des éléments <variant>, <occurrence>, et <mergeMap>.

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

L'élément <resourceData> contient une information sous forme de chaîne de caractères qui peut être :

l'occurrence d'un topique,
une forme de variante d'un nom de base.

Apparaît dans : <occurrence>, <variantName>.

3.9.3.1. Modèle de contenu

<!ELEMENT resourceData  ( #PCDATA ) >

L'élément <resourceData> est déclaré en tant que #PCDATA, indiquant qu'il ne peut contenir que du texte.

3.9.3.2. Attributs

  <!ATTLIST resourceData
     id              ID        #IMPLIED
  >

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

id: Identificateur unique de l'élément.

3.9.3.3. Exemples

Se rapporter aux exemples des éléments <variant>, et <occurence>.

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.10.1. L'élément <mergeMap>

3.10.1.1 - Modèle de contenu
3.10.1.2 - Attributs
3.10.1.3 - Exemples

L'élément <mergeMap> référence l’URI une Topic Map externe au moyen de l’attribut xlink:href. Cet élément est une directive pour fusionner la Topic Map du document courant avec celle référencée, cela en fonction des règles spécifiées en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).

Les enfants de <mergeMap> indiquent les topiques à ajouter aux domaines de validité de toutes les caractéristiques originelles de la Topic Map référencée. Cette modification des domaines est justifiée par des raisons telles que éviter la fusion des topiques ayant le même nom ou encore conserver un distinguo entre les caractéristiques originelles se trouvant dans les Topic MapTopic Maps fusionnées.

Apparaît dans : <topicMap>.

3.10.1.1. Modèle de contenu

<!ELEMENT mergeMap  ( topicRef | resourceRef | subjectIndicatorRef )* >

topicRef: Élément enfant optionnel et répétable qui référence un topique à ajouter aux caractéristiques de la Topic Map référencée.
resourceRef: Élément enfant optionnel et répétable qui référence un sujet adressable à ajouter au domaine de validité des caractéristiques venant de la Topic Map référencée.
subjectIndicatorRef: Élément enfant optionnel et répétable qui référence un indicateur de sujet dont le sujet doit être ajouté au domaine de validité des caractéristiques venant de la Topic Map référencée.

3.10.1.2. Attributs

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

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

id: Identificateur unique de l'élément.
xlink:type: Fournit l’URI de la carte de topique fusionnée.
xlink:href: Contient l’URI de la cible de ce lien. C'est une référence à une carte de topiques qui va être fusionnée au moment de la création des graphes.

3.10.1.3. Exemples

Dans l’exemple suivant, on fusionne la Topic Map « plays.xtm » avec la Topic Map courante, cela en ajoutant les topiques « shakespeare » et « drama » (à la Topic Map courante) aux domaines de validité de toutes les caractéristiques provenant de la Topic Map « plays.xtm ».

  <mergeMap xlink:href="http://www.shakespeare.org/plays.xtm">
    <topicRef xlink:href="#shakespeare"/>
    <topicRef xlink:href="#drama"/>
  </mergeMap>

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

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

L’exemple ci-après est la fusion de la Topic Map « biography.xtm » avec la Topic Map courante, ajoutant la ressource elle-même (en tant que sujet adressable) aux domaines de validité de toutes les caractéristiques de la Topic Map « biography.xtm ». Cette technique permet à un auteur d'utiliser une Topic Map en tant que sujet et définir ainsi un domaine de validité à ses propres topiques dans le résultat fusionné.

  <mergeMap xlink:href="http://www.shakespeare.org/biography.xtm">
    <resourceRef
            xlink:href="http://www.shakespeare.org/biography.xtm"/>
  </mergeMap>

Chapitre 4. Conformité

Table des matières

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

Cette section établit les conditions par lesquelles il peut être précisément revendiqué que des documents ou des applications sont conformes à la spécification XTM.

Un document ou une application est conforme à la spécification XTM seulement si les critères de conformité suivants sont respectés :

il respecte les conditions obligatoires exprimées par les formes verbales devra et doit, et
pour toute condition optionnelle (exprimées par les formes verbales devrait et peut) indiquées, il les respecte de la manière décrite.

Ces critères de conformité doivent être pris en compte par les programmes pour certifier la conformité des documents et des applications à la spécification XTM, ainsi que dans le développement de batteries de tests ou tout autre instrument de mesure et d’analyse de tout document et application se réclamant de cette spécification.

4.1. Vocabulaire utilisé dans cette spécification

Dans cette spécification, les mots-clés « DOIT », « NE DOIT PAS », « EST OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « OPTIONNEL » doivent être interprétés tel que décrit dans la RFC 2119 (se rapporter à [RFC2119]). Toutefois, pour des questions de lisibilité, ces mots n’apparaissent pas en majuscule dans cette spécification.

4.2. Dépendances des traitements XTM

Les traitements XTM dépendent de [XML], [XMLNames], [XLink], [XMLBase], [RFC2396] (et sa mise à jour [RFC2732]).

4.3. L'espace de noms de XTM

L'URI utilisée comme « nom d'espace de nom » (dans le sens défini par la recommandation du W3C sur les espaces de noms dans [XMLNames]) pour référencer la spécification XTM est la suivante :

http://www.topicmaps.org/xtm/1.0/

Les applications souhaitant utiliser dans des documents des traitements définis dans cette spécification doivent utiliser cet espace de nom.

Cette spécification réserve l’usage de la chaîne de caractère bâtie sur les lettres 'X'|'x') ('T'|'t') ('M'|'m')), à la seule fin d’utilisation de cette spécification ou de toute autre spécification produite par TopicMaps.Org.

4.4. Conformité d'un document XTM

Un document de type Topic Map se conforme à la spécification XTM 1.0 si et seulement si toutes les conditions suivantes sont satisfaites, cela en plus des conditions listés ci-dessus (voir Chapitre 4. Conformité) :

Le document est un document XML qui se conforme à la recommandation du W3C XML 1.0, dans la mesure où de telles recommandations ultérieures n'invalident pas des documents XML étant conformes à XTM.
Le document contient au moins un élément <topicMap>.
Chaque élément <topicMap> contenu dans le document est conforme aux contraintes syntaxiques imposées sur les éléments <topicMap> par la DTD XTM 1.0 spécifiée par cette spécification. Un élément <topicMap> n'est pas conforme s'il contient des éléments ou des attributs venant d'autres espaces de noms, et cela à importe quel niveau de récursivité.
Toutes les contraintes syntaxiques ou autres spécifiées par la spécification XTM 1.0 sont appliquées à tout élément <topicMap> contenu dans le document. Quand les éléments <topicMap> sont traités conformément aux spécifications de traitements définies dans cette spécification (voir Annexe F. Spécification des traitements de documents XTM (informatif)), il ne doit pas y avoir d'erreur XTM en sortie.

Un balisage XTM présent dans un document XML à l’extérieur d'un élément <topicMap> n'est pas défini par cette spécification.

4.5. Conformité d'une application XTM

Une application XTM est un logiciel qui :

interprète un élément <topicMap>, produisant une Topic Map traitée conformément à ce qui est défini en annexe (Annexe F. Spécification des traitements de documents XTM (informatif)).
Une application XTM est conforme à la spécification XTM 1.0 si et seulement si les conditions suivantes sont satisfaites :
- Toutes les contraintes spécifiées en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)) relatives à la manipulation des éléments et attributs XTM sont prises en compte.
- Toutes les erreurs XTM sont détectées, et l'application XTM est capable de les retourner.
- Toutes les règles de fusion et celles spécifiées en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)) sont prises en compte.

Références bibliographiques

Vous trouverez ci-après la liste des spécifications dont ce document dérive, dépend, ou renvoie.

[ISO13250] ISO/IEC 13250:2000 Topic Maps: Information Technology -- Document Description and Markup Languages, Michel Biezunski, Martin Bryan, Steven R. Newcomb, ed., 3 Dec 1999. See: http://www.y12.doe.gov/sgml/sc34/document/0129.pdf (PDF, 332K),

[XML] Extensible Markup Language (XML) 1.0 (Second Edition), Tim Bray, Jean Paoli, and C.M. Sperberg-McQueen, Eve Maler, editors. World Wide Web Consortium, W3C Recommendation 6 October 2000. See http://www.w3.org/TR/REC-xml.,

[XLink] XML Linking Language (XLink) Version 1.0., Steve DeRose, Eve Maler, David Orchard, Ben Trafford, editors. World Wide Web Consortium, W3C Candidate Recommendation 3 July 2000. See http://www.w3.org/TR/xlink. XLink processing depends on [XML], [XML Names], [XML Base], and [IETF RFC 2396]. ,

[XMLBase] XML Base (XBase), Jonathan Marsh, editor. World Wide Web Consortium, W3C Proposed Recommendation 8 September 2000. See http://www.w3.org/TR/xmlbase.,

[XMLNames] Namespaces in XML, Tim Bray, Dave Hollander, and Andrew Layman, editors. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, W3C Recommendation 14 January 1999. See http://www.w3.org/TR/REC-xml-names/. ,

[RFC1738] Uniform Resource Locators (URL), IETF (Internet Engineering Task Force) RFC 1738, December 1994. See http://www.ietf.org/rfc/rfc1738.txt. ,

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels, IETF (Internet Engineering Task Force) RFC 2119, S. Bradner, March 1997. See http://www.ietf.org/rfc/rfc2119.txt. ,

[RFC2141] URN Syntax, IETF (Internet Engineering Task Force) RFC 2141, R. Moats, May 1997. See http://www.ietf.org/rfc/rfc2141.txt. ,

[RFC2396] Uniform Resource Identifiers (URI): Generic Syntax, IETF (Internet Engineering Task Force) RFC 2396, August 1998. See http://www.ietf.org/rfc/rfc2396.txt.,

[RFC2732] Format for Literal IPv6 Addresses in URL's, IETF (Internet Engineering Task Force) RFC 2732, 1999. See http://www.ietf.org/rfc/rfc2732.txt.,

Annexe B. Modèle conceptuel XTM (informatif)

B.1. Introduction

B.1.1 - Explication de la notation utilisée dans le modèle conceptuel

Cette annexe présente le modèle conceptuel des Topic Maps XTM. Il a été utilisé pour le présenter graphiquement une notation simple inspirée d’UML. Nous décrivons ci-après les parties conservées de la notation UML.

B.1.1. Explication de la notation utilisée dans le modèle conceptuel

La notation est faite de boites, qui représentent des classes (des types de choses), et des connexions entre ces boites, qui représentent les relations entre ces classes, ou entre les instances de ces classes (des objets du type de ces classes). Il y a quatre types de connexions.

Figure B.1. Ligne se terminant par un triangle vide : d'un sous-type vers un type.

Cette notation peut être visible dans le diagramme initial des « hiérarchies de classes ». Par exemple, le niveau le plus haut indique que « Ressource » et « Non-adressable Subject » sont des sous-types de « Subject ». Un niveau en dessous, « String » est un sous-type de « Ressource ». Lorsqu'un type possède plusieurs sous-types, ils sont rassemblés par une ligne horizontale. Cependant, cela n'indique aucune connexion entre les sous-types (dans notre exemple, la seule information fournie est que les types « String » et « Topic » sont, chacun de leur côté et indépendamment l’un de l’autre, des sous-types de « Resource ».)

Figure B.2. Ligne se terminant éventuellement par une flèche : relation nommée

On peut en voir un exemple dans le diagramme « A topic reifies a subject » : la ligne entre « Topic » et « Subject » définit le fait que la relation nommée « reifies » lie zéro ou plusieurs « Topics » (zéro ou plus s'écrit 0..*) et un « Subject ».

S'il y a une flèche au bout du trait, cela signifie que la relation est unidirectionnelle. Dans cet exemple, cela indique que l'on peut trouver, pour un topique donné, le sujet qu'il réifie, mais que l'on ne peut pas trouver les topiques réfiant un sujet donné.

S'il n'y a pas de flèche, cela signifie qu'il n'y a pas de direction particulière dans la relation. Ainsi, on peut passer par cette relation dans les deux sens.

Une autre variation de cette notation est que les extrémités de la connexion peuvent être libellées. Cela peut être vu dans le diagramme intitulé Nom de base à l’intérieur d’un domaine de validité : le libellé « +Base name string » juste à côté de la classe « String » indique qu'il s'agit d'une « String » servant de « baseNameString » relativement à « BaseName ».

Enfin, la relation peut elle-même être labellisée à l'aide d'un nom entre double-cote, indiquant ainsi la nature de la relation (e.g. « REIFIES »).

Figure B.3. Ligne se terminant par un losange noir : dépendance strict, appelée couramment relation de propriété (diagramme de classe)

Ce cas peut être aperçu dans le diagramme B.6 Nom de base à l’intérieur d’un domaine de validité : la relation « BaseName » vers « Topic » est telle qu’un nom de base n’a de sens que par rapport à un topique.

Figure B.4. Ligne se terminant par un losange vide : un ensemble (diagramme de classe)

Ce cas peut être vu dans le diagramme intitulé Domaine de validité des caractéristiques d'un topique : la relation de « Topic » vers « Scope » est telle que « Scope » est un ensemble de un ou plusieurs topiques.

Dans cette annexe, les noms de classes commencent par une majuscule, comme « Classe ».

B.2. Hiérarchie des classes

Figure B.5. Hiérarchie des classes (diagrammes de classes)

Un sujet est toute chose dont un homme peut discuter ou qu’il peut concevoir. Une ressource est un sujet ayant une identité au sein d'un système informatique. Tout autre sujet est connu comme étant un sujet non-adressable. Il y a plusieurs types de sujets non-adressables. Une classe est un sujet non-adressable. Les différents types de ressources possibles sont les chaînes de caractères (String), les éléments XML (XML element), les attributs XML (XML Attribute), les Topic Maps (Topic Map), les noeuds des Topic Maps (Topic Map Node), les caractéristiques des topiques (Topic Characteristic), etc. Les différents types d'éléments XML (XML element) sont l'élément <topic>, l'élément <association>, et quelques autres. Il y a seulement trois types de noeuds dans les Topic Maps : topique, association, et domaine de validité. Il y a seulement trois types de caractéristiques de topiques : nom de base, occurrence et rôle.

B.3. Relation classe-instance

Figure B.6. Diagramme de classe d’une relation classe-instance

Un Sujet peut être une instance d'une ou plusieurs Classes.

B.4. Topique réifiant un sujet

Figure B.7. Diagramme de classe d'un topique réifiant un sujet

Un Topique est une Ressource qui réifie un Sujet. Il s’agit là du système de représentatation des sujets dans les Topic Maps. La réification permet d'affecter des caractéristiques au topique qui réifie un sujet.

B.5. Référencer le sujet

Figure B.8. Diagramme de classe du référencement d'un sujet

Un topique peut avoir un nombre quelconque d'indicateurs de sujets. Un indicateur de sujet est une ressource permettant de connaître le sujet réifié. Si le sujet est lui-même une ressource, le topique peut directement référencer celle-là.

B.6. Domaine de validité des caractéristiques d'un topique

Figure B.9. Diagramme de classe des domaines de validité des caractéristiques d'un topique

Un domaine de validité est un ensemble de topiques permettant de délimiter la validité d'une assignation de caractéristiques. Si aucun domaine de validité n'est spécifié, le domaine de validité est non-contraint, et les assignations sont toujours valides.

B.7. Nom de base à l’intérieur d’un domaine de validité

Figure B.10. Diagramme de classe des noms de base à l’intérieur d’un domaine de validité

Un nom de base est une chaîne de caractères utilisée pour nommer un Topique au sein d'un domaine de validité. A l’intérieur d’un domaine de validité, deux topiques ne peuvent pas avoir le même nom de base. L'ensemble des noms de base attribués au sein d'un même domaine de validité constitue ainsi un espace de noms, et peut ainsi être utilisé pour identifier les topiques de manière non-ambiguë.

B.8. Occurrence

Figure B.11. Diagramme de classe d’une occurrence

Une Occurrence désigne une Ressource en relation avec un Topique.

B.9. Association entre topiques

Figure B.12. Diagramme de classe d’une association de topiques

Une association relie un topique à un autre. Elle comprend un ou plusieurs rôles, joués par des topiques. Chaque rôle est attribué à zéro ou plusieurs topiques impliqués dans cette association. Ces topiques sont dits être les acteurs des rôles de l'association.

B.10. Topic Map

Figure B.13. Diagramme de classe d’une Topic Map

Une Topic Map comprend zéro ou plusieurs noeuds de Topic Map (des topiques, des domaines de validité, et des associations). Plusieurs topiques d’une même Topic Map peuvent réifier le même sujet. La Topic Map est dite « cohérente » quand aucun sujet n'est réifié par plusieurs topiques.

Annexe C. Passage du modèle conceptuel XTM à une syntaxe d’échange concrète

Il n’y a pas de correspondance de un pour un entre le modèle conceptuel et la syntaxe d'échange des Topic Map. Il y a plusieurs traductions syntaxiques des objets du modèle conceptuel (intitulés ci-après « objets conceptuels ») :

Une construction syntaxique est l'objet conceptuel.
Une construction syntaxique peut référencer par un URI l'objet conceptuel.
Une construction syntaxique peut représenter l'objet conceptuel.
Enfin, il existe des cas où l'objet conceptuel n'a aucune correspondance directe dans la syntaxe, mais se retrouve sous la forme d’un commentaire lisible par l'homme dans le contenu d'une ressource.

La manière dont la syntaxe d'échange réfère les objets conceptuels est spécifiée dans la section sur la syntaxe XTM sous forme « verbeuse » (voir Chapitre 3. Documentation de la syntaxe XTM). Une spécification un peu plus formelle de ces relations est en cours de développement et sera livrée utlérieurement par TopicMaps.Org.

Annexe D. Déclaration de type de document XTM 1.0 (normatif)

  <!-- ............................................................. -->
  <!-- XML Topic Map DTD  .......................................... -->
  <!-- file: xtm1.dtd
  -->
  <!-- XML Topic Map (XTM) DTD, Version 1.0

       This is XTM, an XML interchange syntax for ISO 13250 Topic Maps.

       XML Topic Map (XTM)
         Copyright 2000-2001 TopicMaps.Org, All Rights Reserved.

       Permission to use, copy, modify and distribute the XTM DTD and its
       accompanying materials for any purpose and without fee is hereby
       granted in perpetuity, provided that the above copyright notice and
       this paragraph appear in all copies. The copyright holders make no
       representation about the suitability of the DTD for any purpose. It
       is provided "as is" without expressed or implied warranty.

          Editors:    Steve Pepper      <pepper@ontopia.net>
                      Graham Moore      <gdm@empolis.co.uk>
          Authors:    Murray Altheim    <altheim@eng.sun.com>
                      Michel Biezunski  <mb@infoloom.com>
                      Sam Hunting       <shunting@etopicality.com>
                      Steven R. Newcomb <srn@coolheads.com>
          Status:     Release
          Version:    v1.0.1
          Revision:   $Id: xtm1.dtd,v 1.2 2001/02/08 16:03:12 pepper Exp $
          PublicId:   "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN"

          Revisions:
  #2001-01-21: removed baseName from occurrence
  #2001-02-02: made variantName optional in variant
  #2001-02-02: changed ID to #IMPLIED on association
  #2001-02-02: changed ID to #IMPLIED on resourceData
  #2001-02-02: changed PLUS to REP on member

  -->
  <!-- Use this URI to identify the default XTM namespace:

           "http://www.topicMaps.org/xtm/1.0/"

       Used to identify the XLink namespace:

           "http://www.w3.org/1999/xlink"
  -->

  <!-- topicMap: Topic Map document element ........................ -->

  <!ELEMENT topicMap
     ( topic | association | mergeMap )*
  >
  <!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
  >

  <!-- topic: Topic element ........................................ -->

  <!ELEMENT topic
     ( instanceOf*, subjectIdentity?, ( baseName | occurrence )* )
  >
  <!ATTLIST topic
     id              ID        #REQUIRED
  >

  <!-- instanceOf: Points To a Topic representing a class .......... -->

  <!ELEMENT instanceOf  ( topicRef | subjectIndicatorRef ) >
  <!ATTLIST instanceOf
     id              ID        #IMPLIED
  >

  <!-- subjectIdentity: Subject reified by Topic ................... -->

  <!ELEMENT subjectIdentity
     ( resourceRef?, ( topicRef | subjectIndicatorRef )* )
  >
  <!ATTLIST subjectIdentity
     id              ID        #IMPLIED
  >

  <!-- topicRef: Reference to a Topic element ...................... -->

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

  <!-- subjectIndicatorRef: Reference to a Subject Indicator ....... -->

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

  <!-- baseName: Base Name of a Topic .............................. -->

  <!ELEMENT baseName  ( scope?, baseNameString, variant* ) >
  <!ATTLIST baseName
     id              ID        #IMPLIED
  >

  <!-- baseNameString: Base Name String container .................. -->

  <!ELEMENT baseNameString  ( #PCDATA ) >
  <!ATTLIST baseNameString
     id              ID        #IMPLIED
  >

  <!-- variant: Alternate forms of Base Name ....................... -->

  <!ELEMENT variant  ( parameters, variantName?, variant* ) >
  <!ATTLIST variant
     id              ID        #IMPLIED
  >

  <!-- variantName: Container for Variant Name ..................... -->

  <!ELEMENT variantName  ( resourceRef | resourceData ) >
  <!ATTLIST variantName
     id              ID        #IMPLIED
  >

  <!-- parameters: Processing context for Variant .................. -->

  <!ELEMENT parameters  ( topicRef | subjectIndicatorRef )+ >
  <!ATTLIST parameters
     id              ID        #IMPLIED
  >

  <!-- occurrence: Resources regarded as an Occurrence ............. -->

  <!ELEMENT occurrence
     ( instanceOf?, scope?, ( resourceRef | resourceData ) )
  >
  <!ATTLIST occurrence
     id              ID        #IMPLIED
  >

  <!-- resourceRef: Reference to a Resource ........................ -->

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

  <!-- resourceData: Container for Resource Data ................... -->

  <!ELEMENT resourceData  ( #PCDATA ) >
  <!ATTLIST resourceData
     id              ID        #IMPLIED
  >

  <!-- association: Topic Association  ............................. -->

  <!ELEMENT association
     ( instanceOf?, scope?, member+ )
  >
  <!ATTLIST association
     id              ID        #IMPLIED
  >

  <!-- member: Member in Topic Association ......................... -->

  <!ELEMENT member
     ( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )* )
  >
  <!ATTLIST member
     id              ID        #IMPLIED
  >

  <!-- roleSpec: Points to a Topic serving as an Association Role .. -->

  <!ELEMENT roleSpec  ( topicRef | subjectIndicatorRef ) >
  <!ATTLIST roleSpec
     id              ID        #IMPLIED
  >

  <!-- scope: Reference to Topic(s) that comprise the Scope ........ -->

  <!ELEMENT scope  ( topicRef  | resourceRef | subjectIndicatorRef )+ >
  <!ATTLIST scope
     id              ID        #IMPLIED
  >

  <!-- mergeMap: Merge with another Topic Map ...................... -->

  <!ELEMENT mergeMap  ( topicRef | resourceRef | subjectIndicatorRef )* >
  <!ATTLIST mergeMap
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
  >

  <!-- end of XML Topic Map (XTM) 1.0 DTD -->

Annexe E. Noyau des indicateurs de sujets publiés de XTM 1.0 (normatif)

  <?xml version="1.0"?>
  <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN"
                            "xtm1.dtd">
  <topicMap id="xtm1.0-psi-core"
      xmlns="http://www.topicmaps.org/xtm/1.0/"
      xml:base="http://www.topicmaps.org/xtm/1.0/">
  <!--
       XTM 1.0 Core Published Subject Indicators (PSIs)

       XML Topic Map (XTM)
         Copyright 2000-2001 TopicMaps.Org, All Rights Reserved.

       Permission to use this document for any purpose and without
       fee is hereby granted to the public in perpetuity, provided
       that the above copyright notice and this paragraph appear in
       all copies. The copyright holders make no representation as
       to its suitability for any purpose. It is provided "as is"
       and without expressed or implied warranty.

          Editors:    Steve Pepper <pepper@ontopia.net>
                      Graham Moore <gdm@empolis.co.uk>
          Status:     Final
          Version:    v1.0
          Revision:   $Id: core.xtm,v 1.3 2001/02/21 21:27:27 pepper Exp $
          PublicId:
            "-//TopicMaps.Org//DOCUMENT XTM 1.0 Core Published Subject Indicators//EN"

          Revisions:
  #2000-12-03: added comments from XTM 1.0 Core
  #2001-02-01: major revision to align with Paris decisions
  #2001-02-01: turned descriptions into occurrences and subject indicators
  -->
  <!-- XTM Published Subject Indicators

       The topic elements in this document are designed to serve as
       published subject indicators for topics declared in other topic
       maps whose subjects are the same as the subjects of these topic
       elements.

       In the referencing topic maps, the addresses used to refer to
       these topic elements must use the unique identifiers (i.e. the
       "URI" values indicated within the occurrences) of these elements,
       because their unique identifiers are permanent; their relative
       positions in the document are not necessarily permanent.
       Addressing may use indirection via a topic element.

       TopicMaps.Org reserves the right to enhance the usefulness of
       these published subject indicators, and to provide additional
       published subject indicators, but only in ways that will not
       negatively impact the value or usefulness of any existing
       conforming topic map documents.

       The subjects of these published subject indicators are described
       in the XTM 1.0 Specification as "mandatory," that is, conforming
       applications must be capable of supporting the use of these
       subjects as described in the XTM 1.0 Specification.

       The subject indicators referenced by these topic elements are the
       portions of the XTM 1.0 Specification that provide their
       normative descriptions. Other topic maps should normally use
       these topic elements as the identity points of these subjects,
       rather than the subject indicators that they themselves
       reference. These topic elements may be edited, at some future
       date, in such a way as to provide additional subject indicators
       that will refer to any portions of future versions of the XTM
       Specification that describe the same subject.
  -->

    <!-- begin: XTM core concepts -->

    <topic id="topic">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-topic"/>
        <subjectIndicatorRef xlink:href="#psi-topic-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>topic</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-topic-description">
          Topic: The core concept of topic; the generic class to
          which all topics belong unless otherwise specified.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#topic
        </resourceData>
      </occurrence>
    </topic>

    <topic id="association">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-association"/>
        <subjectIndicatorRef xlink:href="#psi-association-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>association</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-association-description">
          Association: The core concept of association; the generic class
          to which all associations belong unless otherwise specified.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#association
        </resourceData>
      </occurrence>
    </topic>

    <topic id="occurrence">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-occurrence"/>
        <subjectIndicatorRef xlink:href="#psi-occurrence-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>occurrence</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-occurrence-description">
          Occurrence: The core concept of occurrence; the generic class
          to which all occurrences belong unless otherwise specified.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#occurrence
        </resourceData>
      </occurrence>
    </topic>

    <!-- end: XTM core concepts -->

    <!-- begin: the class-instance relationship -->

    <topic id="class-instance">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-class-instance"/>
        <subjectIndicatorRef xlink:href="#psi-class-instance-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>class-instance relationship</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-class-instance-description">
          Class-instance relationship: The core concept of class-instance;
          the class of association that represents class-instance
          relationships between topics, and that is semantically
          equivalent to the use of &lt;instanceOf&gt; subelements.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#class-instance
        </resourceData>
      </occurrence>
    </topic>

    <topic id="class">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-class"/>
        <subjectIndicatorRef xlink:href="#psi-class-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>class</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-class-description">
          Class: The core concept of class; the role of class as played
          by one of the members of a class-instance association.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#class
        </resourceData>
      </occurrence>
    </topic>

    <topic id="instance">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-instance"/>
        <subjectIndicatorRef xlink:href="#psi-instance-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>instance</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-instance-description">
          Instance: The core concept of instance; the role of instance as
          played by one of the members of a class-instance association.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#instance
        </resourceData>
      </occurrence>
    </topic>

    <!-- end: the class-instance relationship -->

    <!-- begin: the superclass-subclass relationship -->

    <topic id="superclass-subclass">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-superclass-subclass"/>
        <subjectIndicatorRef xlink:href="#psi-superclass-subclass-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>superclass-subclass relationship</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-superclass-subclass-description">
          Superclass-subclass relationship: The core concept of
          superclass-subclass; the class of association that represents
          superclass-subclass relationships between topics.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass
        </resourceData>
      </occurrence>
    </topic>

    <topic id="superclass">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-superclass"/>
        <subjectIndicatorRef xlink:href="#psi-superclass-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>superclass</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-superclass-description">
          Superclass: The core concept of superclass; the role of superclass
          as played by one of the members of a superclass-subclass association.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#superclass
        </resourceData>
      </occurrence>
    </topic>

    <topic id="subclass">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-subclass"/>
        <subjectIndicatorRef xlink:href="#psi-subclass-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>subclass</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-subclass-description">
          Subclass: The core concept of subclass; the role of subclass as
          played by one of the members of a superclass-subclass association.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#subclass
        </resourceData>
      </occurrence>
    </topic>

    <!-- end: the superclass-subclass relationship -->

    <!-- begin: variant name parameter concepts -->

    <topic id="sort">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-sort"/>
        <subjectIndicatorRef xlink:href="#psi-sort-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>suitability for sorting</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-sort-description">
          Suitability for sorting: Suitability of a topic name for
          use as a sort key; for use in the parameters of variant names.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#sort
        </resourceData>
      </occurrence>
    </topic>

    <topic id="display">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-display"/>
        <subjectIndicatorRef xlink:href="#psi-display-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#en"/></scope>
        <baseNameString>suitability for display</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-display-description">
          Suitability for display: Suitability of a topic name for
          display; for use in the parameters of variant names.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#display
        </resourceData>
      </occurrence>
    </topic>

    <!-- end: variant name parameter concepts -->

  <!-- end of XTM 1.0 Core Published Subject Indicators (PSIs) -->

  </topicMap>

En plus de ce noyau des indicateurs de sujets publiés, les Topic Maps XTM pour le langage naturel et les pays (par exemple pour l'internationnalisation des Topic Maps), sont disponibles aux adresses suivantes :

Coeur des indicateurs de sujets publiés XTM 1.0 (core.xtm)
Topiques de langages XTM (language.xtm)
Topiques des pays XTM (country.xtm)

Annexe F. Spécification des traitements de documents XTM (informatif)

F.1. Introduction

Cette annexe présente les traitements minimum qu’un processeur XTM doit garantir pour être conforme à la présente spécification. Au minimum, un processeur XTM doit être capable de traiter un ou plusieurs documents XTM en ayant une représentation interne cohérente de la ou des Topic Maps qu’ils contiennent.

Les caractéristiques de traitements XTM sont données en termes de :

principes d'égalités,
principes d'équivalences,
opérations sur les variantes,
opérations de fusions,
suppression des doublons.

F.2. Principes d'égalités

F.2.1 - Principe 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

Les principes d'égalités suivants établissent les règles qui permettent à un processeur XTM de déterminer l'égalité des parties de Topic Map.

F.2.1. Principe d'égalité des chaînes de caractères

Un processeur XTM conforme doit être capable de comparer deux chaînes de caractères afin de savoir si elles sont égales. Avant comparaison, le processeur doit transcoder toutes les chaînes de caractères en Unicode/ISO 10646. Une fois cette transformation effectuée, le processeur considère que les deux chaînes sont égales si elles sont encodées suivant la même suite de valeurs scalaires. Un processeur XTM conforme peut appliquer en plus d'autres algorithmes.

F.2.2. Principe d'égalité des URI

Un processeur XTM conforme doit considérer que deux URI sont égales quand l’égalité est établie par application des règles définies par le schéma d’URI approprié.

La section 6 de la norme RFC 2396 contient la définition générale relative à la manière dont il faut établir l’égalité de deux URI. Vous trouverez ci-dessous l'ensemble des références aux schémas d'URI que doit supporter un processeur XTM conforme :

http (RFC 1738 section 3.3)
ftp (RFC 1738 section 3.2)
https (RFC 1738 section 3.3)
file (RFC 1738 section 3.10)
urn (RFC 2141),
- Un processeur XTM conforme doit définir une égalité d'URN en se basant sur les règles d'égalité définies dans la section 6 de RFC 2396.
- Un processeur XTM conforme peut définir l'égalité d'URN en se basant sur les définitions de la documentation sur les schémas d'URN particuliers.

F.2.3. Principe d'égalité des domaines de validité

Dans une Topic Map cohérente, un processeur XTM conforme doit établir l’égalité de deux domaines de validité quand ils recouvrent le même ensemble de topiques.

F.2.4. Principe d'égalité d'associations

Un processeur XTM conforme doit établir l’égalité de deux associations quand les assertions suivantes sont vérifiées :

Les associations font parties du même jeu de rôles.
Les ensembles des topiques jouant chaque rôle dans les associations sont égaux.
Les associations instancient les mêmes classes.
Les domaines de validité des associations sont égaux (tel que cette égalité est définie dans le principe d'égalité des domaines de validité).

F.2.5. Principe d'égalité de nom de topique

Deux noms de base sont égaux si les assertions suivantes sont vérifiées :

Les chaînes de caractères qui composent les noms de base sont égales quand le principe d'égalité des chaînes de caractères est vérifié.
Les domaines de validité des noms de base sont égaux au regard du principe d'égalité des domaines de validité.

Les variantes des noms de base sont ignorées lorsque deux noms sont égaux.

F.2.6. Principe d'égalité des occurrences de topiques

Deux occurrences de topiques sont égales si les assertions suivantes sont vérifiées :

Dans le cas de l’élément <resourceRef>, les URI utilisés sont égaux quand on leur applique le principe d'égalité des URI, ou
dans le cas de l’élément <resourceData>, la valeur des données utilisées sont égales quand on leur applique le principe d’égalité des chaînes de caractères.
Les occurrences appartiennent à la même classe.
Les contextes des occurrences sont égales en fonction des principes d'égalité des contextes.

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

Cette section présente les principes d’équivalence entre les différentes représentations syntaxiques par lesquelles des mêmes noeuds de Topic Map peuvent être écrits. Un processeur XTM conforme doit pouvoir reconnaître toutes les variantes des représentations syntaxiques des éléments de construction des Topic Maps listés dans cette section, et les traiter de sorte qu'il soit impossible de reconnaître dans la Topic Map traitée les différentes représentations syntaxiques initiales.

F.3.1. Equivalences entre <subjectIndicatorRef> et <topicRef>

Un élément <subjectIndicatorRef> qui référence un topique A est équivalent à un élément <topicRef> référençant également le topique A.

Un élément <subjectIndicatorRef> qui référence une ressource autre qu'un topique est équivalent à un élément <topicRef> qui référencerait un topique ayant cette même ressource comme un indicateur de sujet.

F.3.2. Equivalences entre <instanceOf> et <association>

Un élément <instanceOf> établit une relation entre le topique T, qu’il référence et l’un de ses trois éléments parents possibles : <topic>, <association> ou <occurrence>.

Cette relation peut être exprimée de manière équivalente par une <association> qui serait une instance du sujet publié « class-instance », et qui aurait deux rôles non-contraints — le rôle « class » et le rôle « instance ». L'acteur du rôle « class » est le topique T. Si l'élément parent de <instanceOf> est un élément <topic>, alors l'acteur du rôle « instance » est un topique qui réifie l'association ou l'occurrence représentée par cet élément parent.

Si une <association> est utilisée pour exprimer une relation de type « classe-instance », le processeur XTM doit générer une erreur si l’une des assertions suivantes est vérifiée :

Le rôle « classe » est joué par un topique dont le sujet est adressable.
L’un des deux rôles « classe » ou « instance » n’est pas un rôle dans l’association.
D’autres rôles que « classe » et « instance » font partie de l’association.

F.3.3. Equivalence de plusieurs membres (éléments <member>) d’un même rôle

Une association contenant plusieurs membres, M1 et M2 pour le même rôle R peut être définie de manière équivalente en utilisant une association contenant un seul membre M3 de rôle R dont l’ensemble des acteurs est l’union des ensembles d’acteurs de rôle R dans les membres M1 et M2.

F.4. Opérations sur les variantes

F.4.1 - Traitement des variantes de domaine de validité

F.4.1. Traitement des variantes de domaine de validité

Le contexte de traitement d’une variante de nom définie au moyen de l’élément <variant> est défini comme étant l’union des paramètres de l’élément <variant> et de tous ses éléments ancêtres <variant>.

Aussi, il est équivalent d’avoir une variante de nom avec un ensemble de paramètres et une variante de nom parente avec le même ensemble de paramètres (la variante de nom courante n’ayant pas elle-même de paramètre).

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 nommage des topiques
F.5.4 - Fusion explicite de Topic Map
F.5.5 - Fusion implicite de Topic Map

F.5.1. Fusion de topiques

Condition de départ :

Deux topiques, A et B doivent être fusionnés.

Résultat obtenu :

Un seul topique M existe.
L’ensemble des caractéristiques de nom de M est égal à l’union de l’ensemble des caractéristiques de noms de A et B.
L’ensemble des indicateurs de sujets de M est égal à l’union des indicateurs de sujets de A et B.
Le sujet adressable de M est équivalent à celui de soit A soit B.
M peut indifféremment remplacer A ou B en tant qu’acteur dans n’importe lequel des rôles qu’il joue dans les associations présentes dans la Topic Map.
L’ensemble des affectations de M en tant qu’occurrence est égal à l’union de ceux de A et B.
A et B n’existent plus.

Condition d’erreur :

Les sujets adressables des topiques A et B sont différents.

Situation avant :

  <topicMap>

    <topic id="t34">
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet.html" />
      </occurrence>
    </topic>

    <topic id="t35">
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Prince Of Denmark</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet_again.html" />
      </occurrence>
    </topic>

    <association>
      <member>
        <roleSpec><topicRef xlink:href="#t-play"/></roleSpec>
        <topicRef xlink:href="#t-hamlet" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#t-character"/></roleSpec>
        <topicRef xlink:href="#t34" />
      </member>
    </association>

    <association>
      <member>
        <roleSpec><topicRef xlink:href="#t-play"/></roleSpec>
        <topicRef xlink:href="#t-hamlet" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#t-character"/></roleSpec>
        <topicRef xlink:href="#t35" />
      </member>
    </association>

  </topicMap>

Situation après

  <topicMap>

  <!--
     Note that the topics are merged and as a result of this the
     association duplicate redundancy rule is invoked. This removes
     the now duplicate association.
  -->

    <topic id="t36">
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Prince Of Denmark</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet.html" />
      </occurrence>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet_again.html" />
      </occurrence>
    </topic>

    <association>
      <member>
        <roleSpec><topicRef xlink:href="#t-play"/></roleSpec>
        <topicRef xlink:href="#t-hamlet" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#t-character"/></roleSpec>
        <topicRef xlink:href="#t36" />
      </member>
    </association>

  </topicMap>

F.5.2. Opération de fusion fondée sur les sujets

Condition de départ :

Deux topiques A et B existent dans la Topic Map M et :

Les URIs des sujets adressables de A et B sont égaux conformément au principe d’égalité des URI, ou
Le topique B est un indicateur de sujet du topique A, ou
Iil existe deux URI U1 et U2 respectivement indicateurs de sujets des topiques A et B et U1 est égal à U2 conformément au principe d’égalité des URI, ou
Il existe deux URI U1 et U2 respectivement indicateurs de sujets des topiques A et B et l’application de traitement XTM a réussi à déterminer par des traitements spécifiques que l’indicateur de sujet référencé par U1 pointe le même sujet que celui référencé par U2.

Résultat obtenu :

Les topiques A et B sont fusionnés avec les conditions amont et avales définies pour l’opération de fusion de topiques.

Situation avant :

  <topicMap>
    <topic id="t1">
      <subjectIdentity>
        <resourceRef xlink:href="http://www.topicmaps.org" />
      </subjectIdentity>
      <baseName>
        <baseNameString>TopicMaps.Org web-site</baseNameString>
      </baseName>
    </topic>

    <topic id="t2">
      <subjectIdentity>
        <resourceRef xlink:href="http://www.topicmaps.org" />
      </subjectIdentity>
      <baseName>
        <baseNameString>The Web-site of TopicMaps.Org</baseNameString>
      </baseName>
    </topic>
  </topicMap>

Situation après :

  <topicMap>
    <topic id="t3">
      <subjectIdentity>
        <resourceRef xlink:href="http://www.topicmaps.org" />
      </subjectIdentity>
      <baseName>
        <baseNameString>TopicMaps.Org web-site</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Web-site of TopicMaps.Org</baseNameString>
      </baseName>
     </topic>
  </topicMap>

Exemple F.1. Les URI des sujets adressables de A et B sont égales

Situation avant :

  <topicMap>
    <topic id="t1">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="http://www.shakespeare.org/plays/hamlet.html" />
        <subjectIndicatorRef xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt" />
      </subjectIdentity>
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
    </topic>

    <topic id="t2">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="http://www.shakespeare.org/plays/hamlet.html" />
      </subjectIdentity>
      <baseName>
        <baseNameString>The Tragedy of Hamlet, Prince of Denmark</baseNameString>
      </baseName>
    </topic>
  </topicMap>

Situation après :

  <topicMap>
    <topic id="t3">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="http://www.shakespeare.org/plays/hamlet.html" />
        <subjectIndicatorRef xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt" />
      </subjectIdentity>
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Tragedy of Hamlet, Prince of Denmark</baseNameString>
      </baseName>
    </topic>
  </topicMap>

Exemple F.2. Les deux topiques ont en commun au moins un URI d’indicateur de sujet

F.5.3. Fusion fondée sur la contrainte de nommage des topiques

Condition de départ :

Deux topiques A et B existent dans la Topic Map M et :

Le topique A a un nom de base B1 dans le domaine de validité S1 et,
le topique B a un nom de base B2 dans le domaine de validité S2 et,
le S1 est égal à S2 conformément à la règle d’égalité des domaines de validité et,
B1 est égal à B2 conformément à au principe d’égalité des noms de base.

Résultat obtenu :

T1 et T2 sont fusionnés conformément à l’opération de fusion de topiques.

Situation avant :

  <topicMap>

    <topic id="t34">
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet.html" />
      </occurrence>
    </topic>

    <topic id="t35">
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Prince Of Denmark</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet_again.html" />
      </occurrence>
    </topic>

    <association>
      <member>
        <roleSpec><topicRef xlink:href="#t-play"/></roleSpec>
        <topicRef xlink:href="#t-hamlet" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#t-character"/></roleSpec>
        <topicRef xlink:href="#t34" />
      </member>
    </association>

    <association>
      <member>
        <roleSpec><topicRef xlink:href="#t-play"/></roleSpec>
        <topicRef xlink:href="#t-hamlet" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#t-character"/></roleSpec>
        <topicRef xlink:href="#t35" />
      </member>
    </association>

  </topicMap>

Situation après :

  <topicMap>

  <!--
     Note that the topics are merged and as a result of this the
     association duplicate redundancy rule is invoked. This removes
     the now duplicate association.
  -->

    <topic id="t36">
      <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
      <baseName>
        <baseNameString>The Prince Of Denmark</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet.html" />
      </occurrence>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet_again.html" />
      </occurrence>
    </topic>

    <association>
      <member>
        <roleSpec><topicRef xlink:href="#t-play"/></roleSpec>
        <topicRef xlink:href="#t-hamlet" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#t-character"/></roleSpec>
        <topicRef xlink:href="#t36" />
      </member>
    </association>

  </topicMap>

Exemple F.3. fusion de noms de topiques dans un domaine de validité non-contraint

F.5.4. Fusion explicite de Topic Map

Condition de départ :

Un élément <mergeMap> est traité dans la Topic Map M et il référence le document de type Topic Map D.
L’élément <mergeMap> contient des références à un ensemble de sujets S au moyen de ses éléments enfants.

Résultat obtenu :

Chaque topique et association de D est ajouté à la Topic Map ; le domaine de validité de chaque nom de base, occurrence et rôle dans les associations issu de D est l’union de l’ensemble des sujets de son domaine de validité originel et de l’ensemble S.

F.5.5. Fusion implicite de Topic Map

Condition de départ :

Un élément <topicRef> est traité.
La référence définie par l’élément <topicRef> est un topique d’une Topic Map M qui n’a pas encore été traitée.
L’application choisit de remplacer la référence définie par <topicRef> par le topique référencé

Résultat obtenu :

Chaque topique et association de M est ajouté à la Topic Map et des fusions et suppressions de doublons additionnelles peuvent être réalisées.

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

F.6.1. Suppression des indicateurs de sujets doublons

Condition de départ :

Un topique A existe dans la Topic Map M et a deux URI de référence d’indicateurs de sujets U1 et U2.
U1 est égal à U2 conformément au principe d’égalité des URI.

Résultat obtenu :

La référence à l’indicateur de sujet spécifié par U2 est supprimée de A.

Situation avant :

<topic id="t1">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.elsinor.dk/hamlet.html" />
      <subjectIndicatorRef xlink:href="http://www.elsinor.dk/hamlet.html" />
    </subjectIdentity>
  </topic>

Situation après :

 <topicMap>
    <topic id="t1">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="http://www.elsinor.dk/hamlet.html" />
      </subjectIdentity>
    </topic>
  </topicMap>

F.6.2. Suppression des noms de topiques doublons

Condition de départ :

Un topique A existe dans la Topic Map M et a un nom de base B1 composé d’une chaîne de caractères N1 dans le domaine de validité S1 et un nom de base B2 composé d’une chaîne de caractères N2 dans le domaine de validité S2.
N1 est égal à N2 conformément au principe d’égalité des chaînes de caractères.
S1 est égal à S2 conformément au principe d’égalité des domaines de validité.

Résultat obtenu :

Un nom de base B3 est créé et est composé d’une chaîne de caractères égale à N1 dans le domaine de validité égal à S1.
Toutes les variantes de B1 sont ajoutées à B3.
Toutes les variantes de B2 sont ajoutées à B3.
B3 est ajouté à l’ensemble des noms de A.
B1 et B2 sont supprimés.

F.6.3. Suppression des associations doublons

Condition de départ :

La Topic Map contient deux associations A1 et A2
A1 est égale à A2 conformément au principe d’égalité des associations.

Résultat obtenu :

A2 est supprimée de la Topic Map

Situation avant :

  <topicMap>
    <!-- definition of required topics
    ...
    -->
    <association id="a34">
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
        <topicRef xlink:href="#ctb" />
      </member>
    </association>

    <association id="a35">
     <member>
       <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
       <topicRef xlink:href="#gdm" />
       <topicRef xlink:href="#ctb" />
     </member>
    </association>
  </topicMap>

Situation après :

  <topicMap>
    <!-- definition of required topics
    ...
    -->
    <association id="a34">
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
        <topicRef xlink:href="#ctb" />
      </member>
    </association>
  </topicMap>

F.6.4. Suppression d’un acteur de rôle doublon

Condition de départ :

Une association A a comme membres M1 et M2.
M1 et M2 référencent le même topique RT comme étant le topique de définition du rôle.
M1 et M2 référencent le même topique RPT comme étant le topique de définition de l’acteur du rôle.

Résultat obtenu :

M2 est supprimé de l’association A.

Situation avant :

  <topicMap>
    <!-- definition of required topics
    ...
    -->
    <association id="a34">
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#ctb" />
      </member>
    </association>
  </topicMap>

Situation après :

  <topicMap>
    <!-- definition of required topics
    ...
    -->
    <association id="a34">
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#gdm" />
      </member>
      <member>
        <roleSpec><topicRef xlink:href="#brother" /></roleSpec>
        <topicRef xlink:href="#ctb" />
      </member>
    </association>
  </topicMap>

Annexe G. Transformation de document ISO 13250 vers XTM 1.0

Cette annexe fournit un lien vers le document qui décrit la transformation en syntaxe XTM 1.0 des documents de type Topic Map conformes à la norme [ISO13250].

Annexe H. Remerciements

Le développement de XML Topic Maps (XTM) 1.0 a été un effort collectif, conduit par le groupe des auteurs de TopicMaps.Org. Les éditeurs souhaitent en particulier remercier les personnes suivantes qui ont apporté une contribution significative au travail éditorial :

Michel Biezunski & Steven R. Newcomb (co-chairs, Interchange Syntax Subgroup)
Daniel Rivers-Moore (chair, Conceptual Model Subgroup)
Kal Ahmed (chair, Processing Requirements Subgroup)
Murray Altheim & Sam Hunting (associate editors)

Les membres actifs du groupe des auteurs de TopicMaps.Org au moment de la publication de cette spécification sont :

Murray Altheim (Sun Microsystems)*, Michel Biezunski (InfoLoom, Inc.)*, Jean Delahousse (Mondeca)*, Patrick Durusau (Society of Biblical Literature)*, Eric Freese (Isogen/DataChannel)*, Sam Hunting (Etopicality)*, Andrius Kulikauskas (Minciu Sodas)*, Luis Martinez*, Graham Moore (Empolis)*, Steven R. Newcomb*, Nikita Ogievetsky (Cogitech, Inc.)*, Jack Park (VerticalNet Solutions)*, Steve Pepper (Ontopia)*, Daniel Rivers-Moore (RivCom)*, and Bryan Thompson (GlobalWisdom, Inc.)*.

Nos remerciements vont également à ceux qui ont été invités occasionnellement à participer à nos travaux :

Kal Ahmed (Ontopia)*, Chris Angus (Kalido Ltd), David Duncan (ADIS International)*, Lars Marius Garshol (Ontopia), David Goldstein (Versaware)*, Geir Ove Grønmo (Ontopia), Jason Hanna (EMC)*, Ivan Harré (ADIS International)*, Michael Hoexter*, G. Ken Holman (Crane Softwrights Ltd.)*, Peter Jones (Wrox Press)*, Dianne Kennedy (InfoLoom, Inc.)*, W. Eliot Kimber (Isogen/DataChannel)*, Daniel Koger (Herrick Douglass)*, Benedicte LeGrand (Laboratoire d'Informatique de Paris 6)*, Aaron Lowe (Wrox Press)*, James Mason (Y-12 National Security Complex), Norbert Mikula (DataChannel)*, Peter Newcomb (Epremis Corporation), Laurent Olivry (Electricité de France), Eugene Pereira (CCH)*, Christina Portillo (Boeing)*, Hans Holger Rath (Empolis), Adrian Rivers (RivCom), Vishal Shah (NEC)*, Daniel Speck (The Bureau of National Affairs)*, Drew Stevens (McKinsey & Company)*, Bliksem Tobey (McKinsey & Company)*, Bernard Vatant (Mondeca), Jenny Watson (Wrox Press)*, Matthew West (Shell Services International), and Ann Wrightson (Ontopia).

Enfin nous remercions tous ceux qui ont faits part de leurs commentaires, ainsi que les sociétés qui ont aidé au dévelopement de XTM au travers de l’engagement de leurs ressources précieuses.

Finalement, nous aimerions remercier la société Shakespeare & Company de nous avoir donné la permission d’utiliser l’URL de leur site Web dans nos exemples.

*membres fondateurs de TopicMaps.Org.