XML Topic Maps (XTM 1.0)

Spécification de TopicMaps.Org

Traduction française

Historique des versions
Version 1.016/07/2003Alain Herbuel

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

Version 2.001/09/2003Alain Herbuel

Relecture et corrections, amélioration des CSS.

Version 3.009/09/2003Jean-Jacques Thomasson

Relecture et corrections.

Version 4.021/09/2003Alain Herbuel

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


Table des matières

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

Liste des illustrations

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

Liste des exemples

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

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.

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

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

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

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

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

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

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

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

Ressource d'information adressable

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

Sujet adressable

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

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

Voir aussi Contrainte sur la dénomination de topique.

Caractéristiques

Voir caractéristique de topique.

Topic Map cohérente

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

Membre
Fusion

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

Sujet non adressable

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

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

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

PSI

Voir Indicateur de sujet publié.

Indicateur de sujet publié

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

Réification

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

Ressource

Voir ressource d’information adressable.

Rôle

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

Portée

Voir aussi contexte non contraint .

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

Sujet

Voire aussi identité de sujet, indicateur de sujet .

Identité de sujet
Indicateur de sujet

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

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

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

Suivant le cas :

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

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

Affectation de caractéristique de Topique

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

Carte de topique
Document de type Topic Map

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

Noeud d'un document de type Topic Map

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

Nom de topique
Contrainte sur la dénomination de topique

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

Occurrence de topique

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

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

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

Variant

Voir variante de nom.

Variante de nom

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

Document XTM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

topique

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

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

association

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

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

occurrence

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

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

relation classe / instance

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

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

classe

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

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

instance

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

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

relation superclasse / sous-classe

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

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

superclasse

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

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

sous-classe

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

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

aptitude pour le tri

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

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

aptitude pour l'affichage

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

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

Le terme fusionner couvre deux traitements distincts :

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

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

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

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

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

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.

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>

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

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>

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

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

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

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

Apparaît dans : <topic>.

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

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

<topicRef>

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

<subjectIndicatorRef>

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

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

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

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

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

Apparaît dans : <topic>.

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>

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

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>

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

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>

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

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 :

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

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

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 distingo entre les caractéristiques originelles se trouvant dans les Topic MapTopic Maps fusionnées.

Apparaît dans : <topicMap>.

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.

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.

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.

Une application XTM est un logiciel qui :

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

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.

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.

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

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

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.

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

Il n’y a pas de correspondance à 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 ») :

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.

Dans la version anglaise en ligne de cette DTD, le nom de l’élément type de chaque déclaration d’élément est un lien au sections de cette spécification le concernant. Les noms des éléments types dans les modèles de contenu sont porteurs de liens vers leurs déclarations respectives dans la DTD.
  <!-- ............................................................. -->
  <!-- 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 -->
Dans la version anglaise en ligne de cette spécification, chaque identifiant ("id") de topique ou élément d'association pointe sur la documentation correspondant au sein de cette spécification.
  <?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 :

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.

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.

Condition de départ :

Résultat obtenu :

Condition d’erreur :

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>

Condition de départ :

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

Résultat obtenu :

Condition de départ :

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

Résultat obtenu :

Il n’est pas obligatoire que les domaines de validité S1 et S2 soient contraints.

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

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

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 :

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

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

Enfin nous remercions tous ceux qui ont faits part de leurs commentaires, ainsi que les sociétés qui ont aidé au development 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.