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) :
Ajustement de la feuille de style pour faciliter la lecture. |
Liste des illustrations
Liste des exemples
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 la traduction :
N'hésitez-pas à me remonter vos remarques ou erreurs rencontrées dans cette traduction.
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.
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 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.
Les objectifs ayant prévalu à la conception de XTM sont :
Cette spécification, XML 1.0 pour la syntaxe de balisage [XML], XLink pour la syntaxe de lien [XLink], XML Base pour la résolution des URI [XMLBase], et la spécification IETF URI [RFC2396] (mise à jour par la spécification [RFC2732]), fournissent toutes les informations nécessaires à la compréhension de XTM 1.0 et la création de Topic Maps conformes.
La présente version de la spécification XTM et les informations associées peuvent être distribuées librement aussi longtemps que les textes et notices légales qui s’y rapportent resteront inchangés.
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).
Voir aussi Contrainte sur la dénomination de topique.
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)).
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)).
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.
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)).
Indicateur de sujet publié et maintenu à une adresse connue de tous dans le but de faciliter l’échange et la fusion de Topic Maps.
Voir aussi contexte non contraint .
Cette spécification ne précise pas la manière dont les applications doivent interpréter les portées.
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).
Le fait d’affecter des caractéristiques à un topique donné. Ces dernières étant valides par rapport à un certain domaine de validité.
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é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.
<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>
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>
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é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).
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.
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.
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.
La validité des caractéristiques affectées à un topique dépend d'un domaine de validité (voir Section 2.2.1.6).
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.
Une variante de nom est une alternative au nom de base optimisée pour un traitement particulier, par exemple pour effectuer des tris ou des affichages. Elle peut être n'importe quelle type de ressource, y compris une chaîne de caractères. Les applications choisissent les variantes de noms en fonction de leurs paramètres (voir Section 2.2.2.3).
Les paramètres sont des informations exprimées sous la forme d'un ensemble de topiques servant à définir le domaine de validité approprié à la prise en compte d’une variante de nom (voir Section 2.2.2.2). A partir du nom d'un topique, une application peut examiner les paramètres de ses variantes de noms (si elles existent) afin de choisir une forme plus appropriée de ce nom.
Une occurrence est une information définie comme pertinente pour un sujet donné. L’occurrence est l’une des trois caractéristiques (voir Section 2.2.1.5) possible d’un topique, elle est par conséquent liée à un domaine de validité (voir Section 2.2.1.6). Une occurrence est une instance d'une classe d'occurrences (dénommée type d'occurrence) qui est définie explicitement ou implicitement. Le type d'occurrence par défaut est définie par le sujet publié dénommé « occurrence » (voir Section 2.5).
Pour être manipulées dans une Topic Map, une occurrence doit être une ressource qui :
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 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à.
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).
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 :
Le but d'une Topic Map est de "transporter" un ensemble de connaissances à propos de ressources, ceci dans une couche, ou une carte, "au dessus" des ressources elles-mêmes. Une Topic Map capture des sujets desquels parlent les ressources en question, et les relations existant entre ces sujets, ceci dans une forme indépendante des implémentations.
Les noeuds d'une Topic Map sont les objets créés pour la représentation interne à un système d'une Topic Map. Ils représentent les topiques (voir Section 2.2.1), les associations (voir Section 2.3) et les domaines de validité (voir Section 2.2.1.6).
Une Topic Map cohérente ne contient qu'un seul topique par sujet, et aucune possibilité de suppression de doublons ou de fusion de topiques, tel que ces mécanismes sont présentés en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).
Un 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.
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)).
http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass
Aptitude d’un nom de topique à être affiché ; à utiliser dans les paramètres des variantes de noms.
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 :
Deux topiques sont considérés comme ayant le même sujet si :
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 :
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>
<!ATTLIST topicRef id ID #IMPLIED xlink:type NMTOKEN #FIXED 'simple' xlink:href CDATA #REQUIRED >
L'élément <topicRef> possède les attributs suivants :
Voir les sections 5.2 et 5.4 de [XLink] pour les questions d’utilisation et de conformité.
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>.
<!ATTLIST subjectIndicatorRef id ID #IMPLIED xlink:type NMTOKEN #FIXED 'simple' xlink:href CDATA #REQUIRE >
L'élément <subjectIndicatorRef> possède les attributs suivants :
Voir les sections 5.2 et 5.4 de [XLink] pour les questions relatives à l’utilisation et la conformité.
Référence à un indicateur de sujet publié :
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/language.xtm#en"/>
Référence à une ressource (fictive) qui indique un sujet de manière moins formelle :
<subjectIndicatorRef xlink:href="http://www.shakespeare.org/plays.html#hamlet"/>
Pour plus d'exemples, voir <scope>, <instanceOf>, <subjectIdentity>.
L'élément <scope> consiste en un ou plusieurs éléments <topicRef>, <resourceRef> ou <subjectIndicatorRef>. L'union des sujets correspondant à ces éléments spécifie le domaine de validité dans lequel les caractéristiques associées au topique sont valides.
Une déclaration de caractéristique de topique n’est valide que dans les limites d’une certaine portée. Quand la déclaration d’une caractéristique de topique ne spécifie aucune portée, alors cette caractéristique est valide dans la portée non-contrainte.
Apparaît dans : <baseName>, <occurrence>, <association>.
<!ELEMENT scope ( topicRef | resourceRef | subjectIndicatorRef )+ >
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 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).
<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>
<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).
<!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 :
Voir les sections 5.2 et 5.4 de [XLink] pour les questions relatives à l’utilisation et la conformité, ainsi que la section 3 de [XMLBase] pour des détails sur l'attribut xml:base.
Un élément <topicmap> intégré dans un document XML :
... <topicMap> <!-- mettre ici les déclarations de topiques, d’association et de fusion --> </topicMap> ...
Un élément <topicmap> racine d'un document complet :
<?xml version="1.0"?> <!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN" "file://usr/local/home/gromit/xml/xtm/xtm1.dtd"> <topicMap xmlns='http://www.topicmaps.org/xtm/1.0/' xmlns:xlink='http://www.w3.org/1999/xlink' xml:base='http://www.shakespeare.org/hamlet/'> <!-- mettre ici les déclarations de topiques, d’association et de fusion --> </topicMap>
L'élément <topic> spécifie les caractéristiques nom et occurrence d'un topique. Il possède un identificateur et permet de déclarer la ou les classes qu’il instancie ainsi que l'identité du sujet qu'il réifie.
Par définition, un topique ne réifie qu'un seul sujet. Les topiques ont été conçus pour n’adresser exactement qu’un seul sujet, même si ce dernier est défini implicitement. Pendant un traitement XTM, les topiques ayant le même sujet seront fusionnés, cela en fonction des règles définies en annexe (voir Annexe F. Spécification des traitements de documents XTM (informatif)).
Toutefois, un document de type Topic Map peut contenir plusieurs topiques réifiant le même sujet (pour de plus amples discussions sur le processus de fusion, voir Section 3.10).
La classe dont le topique est une instance est définie par l’élément enfant <instanceOf>, qui adresse soit un topique, soit un indicateur de sujet. S'il n'y a pas d'élément enfant <instanceOf>, la classe par défaut est celle définit par le sujet publié topique.
Un élément <topic> spécifie zéro ou plusieurs noms et occurrences pertinents pour son sujet. Les occurrences sont spécifiées au moyen des éléments enfants <occurrence>.
Apparaît dans : <topicMap>
<!ELEMENT topic ( instanceOf*, subjectIdentity?, ( baseName | occurrence )* ) >
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 )* ) >
Élément optionnel qui permet de référencer un sujet adressable.
Élément enfant optionnel et répétable qui référence un élément topique avec lequel il partage un même sujet.
Élément enfant optionnel et répétable qui référence un indicateur de sujet.
<topic id="dk"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/country.xtm#dk"/> </subjectIdentity> </topic>
<topic id="da"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://www.cia.gov/cia/publications/factbook/geos/da.html"/> </subjectIdentity> </topic>
<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>
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>.
<!ELEMENT baseName ( scope?, baseNameString, variant* )>
<topic id="shakespeare"> <baseName> <baseNameString>William Shakespeare</baseNameString> </baseName> </topic>
<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>
<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>
<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 <baseNameString> permet de spécifies le nom de base du topique défini par son ancêtre <topic>.
Apparaît dans : <baseName>.
<!ELEMENT baseNameString (#PCDATA)>
Cet élément ne contient que des données de type caractères (et donc aucun sous-élément).
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>.
<!ELEMENT variant ( parameters, variantName?, variant* ) >
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>
<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 <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>.
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>.
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>.
<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>
<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>
<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 <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>.
<!ELEMENT member ( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )+ ) >
Élément enfant optionnel qui précise le rôle joué par le membre dans l'association.
Élément enfant répétable qui référence le topique jouant le rôle spécifié.
Élément enfant répétable qui référence la ressource jouant le rôle spécifié.
élément enfant répétable qui référence l’indicateur de sujet du sujet jouant le rôle spécifié.
L'élément <roleSpec> spécifie le rôle joué par un membre d'une association.
Apparaît dans : <member>.
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>.
<!ELEMENT occurrence ( instanceOf?, scope?, ( resourceRef | resourceData ) ) >
Élément enfant optionnel qui spécifie la classe d’appartenance de l'occurrence.
Élément optionnel qui spécifie le domaine de validité de l’occurrence.
Élément enfant qui référence la ressource qui sert d’occurrence au topique.
Élément enfant contenant directement la ressource qui sert d’occurrence au topique.
<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>
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 :
Apparaît dans : <member>, <mergeMap>, <occurrence>, <scope>, <subjectIdentity>, et <variantName>.
L'élément <resourceData> contient une information sous forme de chaîne de caractères qui peut être :
Apparaît dans : <occurrence>, <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 distinguo entre les caractéristiques originelles se trouvant dans les Topic MapTopic Maps fusionnées.
Apparaît dans : <topicMap>.
<!ELEMENT mergeMap ( topicRef | resourceRef | subjectIndicatorRef )* >
<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>
<mergeMap xlink:href="http://www.shakespeare.org/biography.xtm"> <resourceRef xlink:href="http://www.shakespeare.org/biography.xtm"/> </mergeMap>
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 :
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.
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.
Les traitements XTM dépendent de [XML], [XMLNames], [XLink], [XMLBase], [RFC2396] (et sa mise à jour [RFC2732]).
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é) :
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 :
Une application XTM est conforme à la spécification XTM 1.0 si et seulement si les conditions suivantes sont satisfaites :
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.
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 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 ».
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.
<?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 <instanceOf> 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>
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.
Deux noms de base sont égaux si les assertions suivantes sont vérifiées :
Les variantes des noms de base sont ignorées lorsque deux noms sont égaux.
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.
<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>
<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>
Deux topiques A et B existent dans la Topic Map M et :
<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>
<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
<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>
<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
Deux topiques A et B existent dans la Topic Map M et :
<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>
<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
<topic id="t1"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://www.elsinor.dk/hamlet.html" /> <subjectIndicatorRef xlink:href="http://www.elsinor.dk/hamlet.html" /> </subjectIdentity> </topic>
<topicMap> <topic id="t1"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://www.elsinor.dk/hamlet.html" /> </subjectIdentity> </topic> </topicMap>
<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>
<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>
<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>
<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>
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].