XML Topic Maps (XTM) 1.0

Especificación TopicMaps.Org

Traducción al español

Última versión:

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

Esta versión:

http://www.topicmaps.org/xtm/1.0/xtm1-20010806.html

Autores:

Miembros del Grupo de Autores de TopicMaps.Org;

Ver Agradecimientos

Editores:

Steve Pepper mailto:pepper@ontopia.net

Graham Moore mailto:gdm@empolis.co.uk

Revisión:

$Id: index.html,v 1.16 2001/08/06 14:31:44 pepper Exp $

Resumen

Esta especificación provee un modelo y una gramática para representar la estructura de recursos de información utilizados para definir tópicos y las asociaciones (relaciones) entre ellos. Los nombres, los recursos, y las relaciones se dice que son características de conceptos abstractos, que se denominan tópicos. Los tópicos tienen sus características dentro de alcances: es decir, los contextos limitados dentro de los cuales los nombres y los recursos son considerados como sus características nombre, recurso y relación. Uno o más documentos interrelacionados que empleen esta gramática se denomina mapa de tópicos (Topic Map).

TopicMaps.Org es un consorcio de grupos independiente que desarrolla la aplicabilidad del paradigma mapa de tópicos [ISO13250] a la World Wide Web mediante la adopción de la familia de especificaciones XML.

Esta especificación describe la versión 1.0 de XML Topic Maps (XTM) [XTM], un modelo abstracto y una gramática XML para el intercambio de mapas de tópicos diseñados para la Web, escrita por los miembros del Grupo de Autores de TopicMaps.Org. Podrá encontrar más información sobre XTM y TopicMaps.Org en http://www.topicmaps.org/about.html.

Todas las versiones de la especificación XTM son públicas, tal como disponen los estatutos de TopicMaps.Org.

Status de este documento

Esta sección describe el status de este documento en el momento de su publicación. Otros documentos pueden reemplazarlo. Para la última versión, acudir siempre a la URL mencionada al inicio.

Este documento ha sido revisado por el Grupo de Autores de TopicMaps.Org y otros grupos interesados, siendo aprobado por este grupo de trabajo como especificación de TopicMaps.Org. Es un documento estable y puede utilizarse como material de referencia o ser citado como normativa de referencia desde otro documento.

La versión en inglés de esta especificación es la única versión normativa. Sin embargo, la traducción de este documento a otras lenguas es alentada activamente por TopicMaps.Org.

Se mantendrá una lista de erratas en la dirección http://www.topicmaps.org/xtm/1.0/errata.html para esta especificación.

Por favor, informe de los errores en este documento a xtm-editor@topicmaps.org.

Sobre la traducción

Este documento es una traducción de la especificación XML Topic Maps (XTM) 1.0, realizada por Mª Jesús Colmenero Ruiz. Esta versión traducida puede contener errores ausentes en el original, debidos a la propia traducción. La versión original en inglés, única normativa, se encuentra en la dirección http://www.topicmaps.org/xtm/1.0/xtm1-20010806.html.

No dude en enviar comentarios o errores encontrados en este documento, con el fin de mejorarlo, a la dirección de correo electrónico "errores y comentarios"

Sumario

1. 1. Introducción

1. 1.1. Orígenes
2. 1.2. Objetivos
3. 1.3. Terminología

1. 2. Conceptos

1. 2.1. Introducción sencilla a los Mapas de Tópicos
2. 2.2. Descripción de los conceptos de los Mapas de Tópicos

1. 2.2.1. Tópico

1. 2.2.1.1. Concepto
2. 2.2.1.2. Cosificación
3. 2.2.1.3. Identidad de concepto
4. 2.2.1.4. Indicador de concepto
5. 2.2.1.5. Característica de tópico
6. 2.2.1.6. Alcance

1. 2.2.2. Nombre

1. 2.2.2.1. Nombre base
2. 2.2.2.2. Variante de nombre
3. 2.2.2.3. Parámetros

1. 2.2.3. Ocurrencia

1. 2.2.4. Asociación

1. 2.2.4.1. Miembro
2. 2.2.4.2. Rol
3. 2.2.4.3. Clase-Instancia
4. 2.2.4.4. Superclase-Subclase

1. 2.2.5. Mapa de tópicos

1. 2.2.5.1. Nodo de mapa de tópicos
2. 2.2.5.2. Mapa de tópicos consistente
3. 2.2.5.3. Documento mapa de tópicos
4. 2.2.5.4. Documento XTM

1. 2.3. Conceptos publicados

1. 2.3.1. Introducción
2. 2.3.2. Indicadores de Conceptos Publicados XTM obligatorios

1. 2.4. Unión

1. 3. Documentación de la Sintaxis XTM

1. 3.1. Introducción a la sintaxis XTM
2. 3.2. Referencias a Tópicos e Indicadores de Concepto

1. 3.2.1. Elemento <topicRef>
2. 3.2.2. Elemento <subjectIndicatorRef>

1. 3.3. Alcance y Contexto

1. 3.3.1. Elemento <scope>

1. 3.4. Clases e Instancias

1. 3.4.1. Elemento <instanceOf>

1. 3.5. Mapa de Tópicos

1. 3.5.1. Elemento <topicMap>

1. 3.6. Tópicos y Conceptos

1. 3.6.1. Elemento <topic>
2. 3.6.2. Elemento <subjectIdentity>

1. 3.7. Nombres de Tópicos

1. 3.7.1. Elemento <baseName>
2. 3.7.2. Elemento <baseNameString>
3. 3.7.3. Elemento <variant>
4. 3.7.4. Elemento <variantName>
5. 3.7.5. Elemento <parameters>

1. 3.8. Asociaciones y Miembros

1. 3.8.1. Elemento <association>
2. 3.8.2. Elemento <member>
3. 3.8.3. Elemento <roleSpec>

1. 3.9. Ocurrencias y Recursos

1. 3.9.1. Elemento <occurrence>
2. 3.9.2. Elemento <resourceRef>
3. 3.9.3. Elemento <resourceData>

1. 3.10. Unión

1. 3.10.1. Elemento <mergeMap>

1. 4. Conformidad

1. 4.1. Conformidad del Vocabulario XTM
2. 4.2. Dependencias de Procesamiento XTM
3. 4.3. El espacio de nombres XTM
4. 4.4. Conformidad del Documento XTM
5. 4.5. Conformidad de Aplicación XTM

1. Anexos

1. Anexo A: Referencias (Informativo)
2. Anexo B: Modelo Conceptual XTM (Informativo)
3. Anexo C: Modelo Conceptual XTM para el mapeo de la Sintaxis de Intercambio (Informativo)
4. Anexo D: Definición de Tipo de Documento XTM 1.0 (Normativo)
5. Anexo E: Indicadores de conceptos publicados básicos XTM 1.0 (Normativo)
6. Anexo F: Requisitos de Procesamiento XTM (Informativo)
7. Anexo G: Transformación de Documentos ISO 13250 a XTM (Informativo)
8. Anexo H: Agradecimientos (Informativo)

1. Introducción

1.1 Orígenes

XML Topic Maps (XTM) es un producto del grupo de autores de TopicMaps.Org creado en 2000 por un consorcio independiente llamado TopicMaps.Org, presidido, originalmente, por Michel Biezunski y Steven R. Newcomb y, en la fecha de la difusión de esta especificación, por Steve Pepper y Graham Moore. Los miembros integrantes del Grupo de Autores están recogidos en el Anexo H: Agradecimientos

Los orígenes del paradigma mapa de tópicos datan de 1993, cuando fue expresado inicialmente como documento de trabajo en el contexto del Grupo de Davenport. El paradigma se desarrolló después de manera más completa en el contexto del Instituto de investigación GCA (conocido ahora como IDEAlliance), en una actividad llamada "Convenciones para la Aplicación de HyTime", durante y tras el cual el paradigma se desarrolló, implemento y promulgó de forma independiente. A principios del 2000, tras varios años de esfuerzo continuado de un grupo internacional de personas, el paradigma mapa de tópicos fue completamente formalizado por primera vez como un estándar internacional ISO, ISO/IEC 13250:2000. Casi inmediatamente después, TopicMaps.Org se fundó para desarrollar la aplicabilidad del paradigma a la World Wide Web, y mostrar su enorme potencial para mejorar la recuperación y manejo de la información.

1.2. Objetivos

Los objetivos de diseño de XTM son:

1. XTM deberá ser directamente utilizable en Internet.
2. XTM deberá soportar una amplia variedad de aplicaciones.
3. XTM deberá ser compatible con XML, XLink, y la ISO 13250.
4. Deberá ser fácil escribir programas que procesen documentos XTM.
5. El número de características opcionales en XTM debe mantenerse en el mínimo absoluto, idealmente cero.
6. Los documentos XTM deberán ser legibles para las personas y razonablemente claros.
7. El diseño XTM deberá ser preparado rápidamente.
8. El diseño de XTM deberá ser formal y conciso.
9. Los documentos XTM deberán ser fáciles de crear.
10. La brevedad del marcado XTM tiene una importancia mínima.

Esta especificación, junto a XML 1.0 para la sintaxis de marcado [XML], XLink 1.0 para la sintaxis de enlaces [XLink], XML Base para la resolución de los URI de base [XML Base], y la especificación URI IETF [RFC 2396] (actualizada por [RFC 2732]), proporciona toda la información necesaria para entender XTM 1.0 y crear documentos mapa de tópicos conformes.

Esta versión de la especificación XTM y sus materiales asociados pueden distribuirse libremente, siempre que el texto y los avisos legales permanezcan intactos.

1.3. Terminología

La terminología usada para describir documentos XTM está definida en el cuerpo de esta especificación y sus anexos. Los términos definidos en esta sección son usados para la construcción de dichas definiciones.

Alcance

1. El ámbito de validez de una asignación de característica al tópico. El contexto en el cual un nombre o una ocurrencia se asigna a un tópico dado, y el contexto en el cual los tópicos están relacionados mediante asociaciones.
2. El conjunto de tópicos especificados vía un elemento <scope>.

Véase también Alcance no limitado.

Esta especificación no impone límites sobre cómo deben las aplicaciones interpretar el alcance.

Alcance no limitado

Ausencia de un alcance especificado en la asignación de característica al tópico

Asignación de característica al tópico

Acto de afirmar que un tópico dado tiene una característica particular. Dichas afirmaciones se entiende que son válidas en el ámbito de un cierto alcance.

Asociación

1. Una relación entre tópicos aseverada por un elemento <association>.
2. Un elemento <association>

Característica de tópico

Uno de los siguientes:

1. un nombre de tópico,
2. una ocurrencia de tópico, o
3. un rol jugado por un tópico en una asociación

Los nombres de tópico, las ocurrencias, y los roles jugados en las asociaciones se conocen colectivamente como características.

Véase también nombre de tópico, ocurrencia de tópico, y rol.

Características

Véase característica de tópico.

Concepto

1. Cualquier cosa sobre la que pueda hablarse o ser concebida por un ser humano. En el sentido más genérico, un concepto es cualquier cosa, con independencia de si existe o tiene otras características específicas, sobre la que puede afirmarse cualquier cosa con cualquier significado.
2. Cualquier cosa sobre la que el autor de un mapa de tópicos elige razonar.
3. Cualquier cosa que es cosificada por un tópico en un mapa de tópicos; el principio organizativo de un tópico. Los seres humanos son las autoridades últimas para determinar los conceptos de los tópicos.

Véase también Identidad del concepto, Indicador de concepto.

Concepto direccionable

Un recurso de información direccionable, considerado como un concepto en sí mismo, y no considerado en términos de lo que un autor quiere significar mediante él. La identidad de un concepto direccionable es por definición directamente computable. (Cf. concepto no-direccionable)

Concepto no-direccionable

Un concepto que existe fuera de los límites del ordenador y cuya identidad es, por tanto, no computable. Ejemplos de conceptos no-direccionables son William Shakespeare, la obra Hamlet y su edición de 1604-05, el personaje Hamlet, el concepto de venganza, la empresa Shakespeare y Cía, etc. La identidad de un concepto no-direccionable sólo puede ser establecida indirectamente, por ejemplo mediante el uso de un indicador de concepto.

Documento mapa de tópicos

Un documento que contiene uno o más mapas de tópicos de acuerdo a esta especificación. Puede serializarse con propósitos de almacenamiento o intercambio en una sintaxis dirigida por ésta o alguna otra especificación.

Documento XTM

Un documento mapa de tópicos que está expresado en la sintaxis definida por esta especificación.

Unión

1. El proceso de unir dos mapas de tópicos, bien como resultado de directrices <mergeMap> explícitas, bien por razones específicas de la aplicación.
2. El proceso de unir dos tópicos.

Las reglas que dirigen todas las formas de unión se especifican en el Anexo F: Requisitos de Proceso de XTM

Identidad del concepto

1. El elemento hijo <subjectIdentity> de un elemento <topic>.
2. Aquéllo que hace idénticos dos conceptos, o distingue un concepto de otro. La determinación de la identidad del concepto está asistida, y puede automatizarse, mediante el uso de indicadores de concepto publicados.
3. Un criterio para unir tópicos tal y como se define en el Anexo F: Requisitos de Proceso de XTM.

Indicador de concepto

Un recurso mediante el que el autor de un mapa de tópicos intenta dar una indicación positiva, sin ambigüedad, de la identidad de un concepto. Hay tres formas de señalar un concepto en un mapa de tópicos:

1. Señalar vía un elemento <topicRef> a un elemento <topic> que comparta el mismo concepto;
2. Señalar vía un elemento < subjectIndicatorRef> a un recurso que recoge el concepto;
3. Señalar vía un elemento <resourceRef> a un recurso que es el concepto.

El concepto señalado por un indicador de concepto puede ser direccionable o no direccionable. (Nótese que en el caso 3, el concepto es necesariamente direccionable, puesto que es un recurso.)

Indicador de concepto publicado

Un indicador de concepto que se publica y se mantiene en una dirección anunciada cuyo propósito es facilitar el intercambio y la unión de mapas de tópicos.

Restricción de denominación de tópico

El límite, impuesto por paradigma "mapa de tópicos", de que los tópicos que tienen el mismo nombre base en el mismo alcance se refieren implícitamente al mismo concepto y, por tanto, deber unirse.

Mapa de tópicos

1. Una colección de tópicos, asociaciones, y alcances que pueden existir en una de dos formas:
2. 1. un formato de intercambio serializado (p.ej. un documento mapa de tópicos expresado en sintaxis XTM), o
   2. alguna forma de aplicación interna, como la que está limitada por los Requerimientos de Proceso XTM definidos en el Anexo F.
3. El elemento documento mapa de tópicos (<topicMap>)expresado usando la sintaxis XTM.

Mapa de tópicos consistente

Un mapa de tópicos en el que existe un solo tópico por concepto y no hay posibilidad de unir o suprimir duplicados, tal como se define en el Anexo F: Requerimientos de Proceso XTM.

Mapa de tópicos procesado

La colección de tópicos, asociaciones, y alcances que han sido procesados por la aplicación de proceso tal como se define en el Anexo F: Requerimientos de Proceso XTM.

Miembro

1. Un elemento hijo (<member>) de un elemento <association>.
2. Un conjunto de tópicos que juegan un determinado rol en una asociación.

Nodo de un mapa de tópicos

Un objeto (en la representación de un mapa de tópicos interna del sistema) que representa un tópico, asociación o alcance.

Nombre base

1. Un elemento hijo (<baseName>) de un elemento <topic>.
2. Un nombre característico de un tópico proporcionado por el contenido de un elemento <baseNameString>. Los nombres base deben ser únicos para un alcance dado. (véase Restricción de la denominación de tópicos).

Véase también variante de nombre.

Nombre de tópico

1. Un nombre base característico de un tópico (incluidas las variantes del nombre base).
2. (Informalmente) La cadena de caracteres especificada como nombre de un tópico usando un elemento <baseNameString>.

Ocurrencia

1. Un elemento hijo (<occurrence>) de un elemento <topic>.
2. Una ocurrencia de tópico.

Ocurrencia de tópico

Un recurso que contiene información considerada relevante para un concepto dado. Para ser expresado en un mapa de tópicos XTM, dicho recurso puede ser:

1. direccionado vía una URI usando un elemento <resourceRef>, o
2. situado en el documento XTM como un elemento <resourceData>.

Parámetros

1. Un elemento hijo (<parameters>) de un elemento <variant>.
2. Información, en la forma de un conjunto de tópicos, que expresa el contexto de proceso apropiado para una variante de nombre.

PSI

Véase indicador de concepto publicado.

Recurso

Véase recurso de información direccionable.

Recurso de información direccionable

Un recurso de información cuya identidad puede ser procesada por el ordenador (es decir, un sistema informático puede recuperar el recurso y hacer comparaciones determinísticas entre él y algún otro recurso para establecer su identidad o diferencia). Un ejemplo de un recurso de información direccionable es la versión online de este documento. En esta especificación, el término recurso es utilizado como sinónimo de recurso de información direccionable a menos que se especifique lo contrario.

Cosificación

El acto de crear un tópico. Cuando algo es cosificado se convierte en el concepto del tópico así creado; cosificar algo es, por tanto, crear un tópico del cual ese algo es el concepto. La cosificación de un concepto permite a las características de tópico ser asignadas al tópico que lo simboliza: en otras palabras, hace posible el análisis discursivo del concepto en términos del paradigma mapa de tópicos.

Requisitos de procesamiento

Los requisitos de procesado llevados a cabo por un procesador XTM conforme tal como se define en el Anexo F: Requisitos de Procesamiento XTM.

Rol

El papel que juega un tópico como miembro de una asociación; la naturaleza de su participación en esa asociación.

Tipo de asociación

1. Una de las clases de asociación.
2. La clase de asociación especificada por un elemento hijo <instanceOf> del elemento <association>. Una asociación debe pertenecer a una sóla clase.
3. Un tópico cuyo concepto es una clase de asociación.

Tipo de ocurrencia

1. Una de las clases de ocurrencia de tópico.
2. La clase de ocurrencia de un tópico especificada por un elemento hijo <instanceOf> de un elemento <occurrence>.
3. Un tópico cuyo concepto es una clase de ocurrencia de tópico.

Tipo de tópico

1. Una de las clases de tópico.
2. Una clase de tópico especificada por un elemento hijo <instanceOf> de un elemento <topic>. Un tópico puede pertenecer a más de una clase.
3. Un tópico cuyo concepto es una clase de tópico.

Tópico

1. Un recurso que actúa como sustituto (proxy) para algún concepto; el sistema de representación del mapa de tópicos de ese concepto. La relación entre un tópico y su concepto está definida como una relación de cosificación. La cosificación de un concepto permite asignar características de tópico al tópico que lo simboliza.
2. Un elemento <topic>.

Variante

Véase variante de nombre.

Variante de nombre

Una forma alternativa de un nombre base, optimizado para un propósito computacional particular, tal como su ordenación o presentación en pantalla.

2. Conceptos

Esta sección describe los conceptos necesarios para entender las construcciones de XML Topic Maps (XTM).

El propósito de un mapa de tópicos es transmitir el conocimiento contenido en recursos a través de una capa sobrepuesta, o mapa, de los propios recursos. Un mapa de tópicos capta los conceptos de los que tratan los recursos, y las relaciones entre conceptos, en una forma en que es independiente de la implementación.

Los conceptos clave en los mapas de tópicos son tópicos, asociaciones, y ocurrencias.

Un tópico es un recurso situado dentro del ordenador que sustituye a (o "simboliza") algún concepto del mundo real. Ejemplos de dichos conceptos pueden ser la obra Hamlet, el autor William Shakespeare, o la relación "autoría".

Los tópicos pueden tener nombres. También pueden tener ocurrencias, es decir, recursos de información que se consideran relevantes de algún modo para su concepto. Por último, los tópicos pueden participar en relaciones, denominadas asociaciones, en las cuales tienen roles como miembros.

Así, los tópicos tienen tres tipos de características: nombres, ocurrencias, y roles jugados como miembros de asociaciones. La asignación de dichas características se considera que son válidas para un cierto alcance, o contexto.

Los mapas de tópicos pueden ser combinados en uno solo. La unión puede tener lugar a discreción del usuario o de la aplicación (durante su procesamiento), o puede ser indicada por el autor del mapa de tópicos en el momento de su creación.

La siguiente sección proporciona una introducción sencilla usando un ejemplo simple tomado del dominio de la edición de enciclopedias. Le sigue una panorámica más detallada de los conceptos de los mapas de tópicos. Para consultar una lista de los tipos de elementos XML declarados en un mapa de tópicos, véase Sección 3.1. Introducción a la sintaxis XTM.

2.1. Introducción sencilla a los Mapas de Tópicos

Para ilustrar el uso de la notación mapa de tópicos definida en esta especificación, considérese el siguiente ejemplo. Supongamos que queremos registrar, de manera independiente del dispositivo e independiente de la implementación, la información sobre el contenido temático de un documento para hacer posible su inclusión en el índice de materias de una enciclopedia en formato electrónico.

Para varios conceptos —por ejemplo, William Shakespeare, Ben Jonson, sus obras Hamlet y Volpone, y las ciudades de Londres y Stratford, entre miles de otros— desearíamos registrar todas las ubicaciones en la enciclopedia —pasajes de texto, o imágenes, o grabaciones en una enciclopedia multimedia—; donde son analizados, descritos o mencionados. Hablaremos de estas ubicaciones como ocurrencias de esos conceptos. Nótese que distintas ocurrencias pueden estar relacionadas con su concepto de muy diferente forma, lo que nos gustaría poder diferenciar. Puede necesitarse distinguir entre análisis en profundidad, menciones breves e ilustraciones para permitir a los usuarios encontrar más rápidamente lo que necesitan.

La enciclopedia con la que trabajamos tiene formato electrónico, por lo que cada ocurrencia de un concepto es un recurso electrónico, para el que podemos dar una dirección electrónica. (Sin entrar en detalle sobre la naturaleza de la dirección, definimos una dirección como una expresión, generalmente corta, que permite a un procesador adecuado localizar un recurso). Son, por tanto, recursos de información direccionables.

Los autores William Shakespeare y Ben Jonson, por el contrario, no son recursos direccionables: no son artefactos electrónicos en absoluto, sino seres humanos. Para representar la conexión entre una ocurrencia de un concepto y el concepto mismo, querríamos simplemente apuntar a cada uno de ellos y decir "esta localización analiza este concepto" (o realizar los gestos equivalentes en alguna notación electrónica, dando la dirección del concepto, la dirección de la ocurrencia y describiendo la relación entre ellos usando marcas).

Sin embargo, debido a que no todos los conceptos son artefactos electrónicos a veces no podemos proporcionar una dirección para el concepto. En su lugar proporcionamos un sustituto electrónico para el concepto, el cual (al ser electrónico) puede tener una dirección. Llamamos a este sustituto un tópico. Cada tópico actúa como un sustituto para algún concepto. Decimos que el tópico "simboliza" el concepto - o hace el concepto "real" para el sistema. La creación de un tópico que simboliza un concepto capacita al sistema para manipular, procesar y asignar características al concepto a través de la manipulación, procesamiento y asignación de características al tópico que lo simboliza. Cuando necesitamos una dirección para el concepto, damos la dirección de un tópico que lo simboliza y actúa como su sustituto dentro del sistema.

En aquellos lugares donde no de lugar a confusión, usaremos a veces los términos tópico y concepto indistintamente; dado que cada tópico simboliza algún concepto y que para cada concepto podemos construir un tópico para cosificarlo, diferenciarlos no siempre es importante.

Dado que nuestra colección completa de información en forma de índice de materias proporciona una especie de mapa de la enciclopedia, indicando donde se mencionan y analizan varios tópicos, denominamos nuestra representación electrónica del índice de materias un mapa de tópicos.

Los tópicos que representan varias de las obras de William Shakespeare podrían tener este aspecto:

<topic id="hamlet">
 <instanceOf>
   <topicRef xlink:href="#obra">
 </instanceOf>
 <baseName>
   <baseNameString>Hamlet, Príncipe de Dinamarca</baseNameString>
 </baseName>
 <occurrence>
    <instanceOf><topicRef xlink:href="#formato-texto-plano"></instanceOf>
    <resourceRef
         xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt">
  </occurrence>
</topic>

<topic id="tempestad">
  <instanceOf>
    <topicRef xlink:href="#obra"></instanceOf>
  <baseName>
    <baseNameString>La Tempestad</baseNameString>
 </baseName>
  <occurrence>
    <instanceOf><topicRef xlink:href="#formato-texto-plano"></instanceOf>
    <resourceRef
        xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws4110.txt">
  </occurrence>
</topic>
      

Nota: Para abreviar, los ejemplos de URIs en esta especificación a veces incluyen sólo un fragmento identificador (p.e.. #obra, arriba). En tales casos, se asume que estos indicadores se refieren a un elemento <topic> situado en otra parte en el mismo mapa de tópicos con un valor del atributo "id" que coincide con el fragmento identificador.

A menudo, en los tesauros e índices de materias es útil indicar las relaciones entre los conceptos: Hamlet y La tempestad son ambas ejemplos de obras, Shakespeare es su autor, Rosencrantz y Guildenstern son personajes de la obra Hamlet, etc. En las obras de referencia tradicionales, este tipo de relaciones se utilizan para guiar al compilador en la creación de referencias cruzadas. Nótese que estas relaciones no se extienden entre las ocurrencias de los conceptos sino entre los propios conceptos; una representación electrónica de ellos puede ser totalmente independiente de las ocurrencias y pudiera aplicarse a colecciones de recursos muy dispares. La representación electrónica de las relaciones entre conceptos, por supuesto, tomará la forma de relaciones, o asociaciones, entre los tópicos que cosifican esos conceptos.

Una asociación que represente la relación entre Shakespeare y la obra Hamlet se parecería a esto:

<association>
  <instanceOf><topicRef xlink:href="#escrita-por"/></instanceOf>
  <member>
    <roleSpec><topicRef xlink:href="#autor"/></roleSpec>
    <topicRef xlink:href="#shakespeare"/>
  </member>
  <member>
    <roleSpec><topicRef xlink:href="#obra"/></roleSpec>
    <topicRef xlink:href="#hamlet"/>
  </member>
</association>
      

Como las asociaciones expresan relaciones que son inherentemente multidireccionales, si "Hamlet fue escrita por Shakespeare", se deriva automáticamente que "Shakespeare escribió Hamlet"; es la misma relación expresada de forma ligeramente distinta. En vez de la direccionalidad, las asociaciones utilizan los roles para distinguir entre las variadas formas de participación que los miembros desempeñan en ellas. Así, el ejemplo anterior puede ser serializado en lenguaje natural de la siguiente manera: "Aquí existe una relación "escrito por" entre Shakespeare (con el rol "autor") y Hamlet (con el rol "obra")". Las relaciones pueden involucrar uno, dos, o más roles.

No hay un límite intrínseco a las clases de relaciones entre los conceptos que podemos registrar de esta manera; para algunos propósitos, vivió en y ejemplo de será suficiente; para otros propósitos, serán de interés relaciones muy diferentes entre conceptos.

Como los tópicos y sus relaciones pueden describirse independientemente de sus ocurrencias en cualquier conjunto dado de recursos de información, pueden esperarse que un conjunto dado de tópicos se puedan conectar, en diferentes aplicaciones, con conjuntos muy diferentes de recursos de información. También al contrario, un conjunto de recursos de información puede ser descrito por distintos mapas de tópicos. Mapas de tópicos diferentes pueden definir tópicos para el mismo concepto; será importante, en la práctica, ser capaces de unir los tópicos que denotan el mismo concepto.

A un nivel abstracto, podemos decir que nuestra enciclopedia se compone de un conjunto de recursos de información direccionables, cada uno de los cuales puede estar localizado dentro de algún recurso de información direccionable mayor y que pertenece a uno o más conceptos. Nuestro índice de materias se compone de los tres elementos siguientes:

1. un conjunto de tópicos, sirviendo cada uno de ellos como un sustituto electrónico para (cosificar) algún concepto, y pudiendo tener cada uno de ellos uno o m&aacute;s nombres
2. los enlaces desde los tópicos a los recursos de información que son considerados ocurrencias de los concepto que esos tópicos cosifican (por ejemplo, analizado-en, mencionado-en, representado-en)
3. las asociaciones entre tópicos (por ejemplo, ejemplo-de, escribió/escrito por, vivió-en)

Utilizamos el término mapa de tópicos para denotar cualquier colección de tales elementos. Nótese que dado que los conceptos, tal como los hemos definido, incluyen a cualquier ser humano acerca del que se desee meditar, analizar, o representar en forma electrónica, no hay una prueba autom&aacute;tica para determinar si dos conceptos son idénticos o no, o si dos tópicos cosifican el mismo concepto o no. Por tanto, los conceptos por sí mismos no tienen una concreción con la descripción formal dada. Tampoco podemos intentar restringir la naturaleza de las relaciones entre tópicos y sus ocurrencias, o entre tópicos y otros tópicos. Por esta razón, el formalismo definido aquí, mientras se desarrollaba históricamente al margen del interés en los problemas de recuperación de conceptos sobre cuerpos de materiales dispares en distintos medios, puede ser aplicado a muchos problemas muy distantes (al menos aparentemente) de las dificultades de la indización de materias para las enciclopedias. La terminología permanece para reflejar los orígenes históricos de los términos, en interés de la claridad y la concrección.

Nótese que dado que los recursos electrónicos de cualquier tipo pueden convertirse en objeto de nuestra atención, pueden también ser tratados como tópicos. (Un cuadro que muestre a William Shakespeare, por ejemplo, es una ocurrencia del tópico que representa William Shakespeare, pero puede mencionarse también como un cuadro, en una historia del arte, o en un an&aacute;lisis de formatos gr&aacute;ficos, o en un inventario de recursos digitales- o en un mapa de tópicos).

2.2. Descripción de los conceptos de los Mapas de Tópicos

Esta sección proporciona una panor&aacute;mica completa de todos los conceptos de los mapas de tópicos. Se basa en gran parte en las definiciones de 1.3. Terminología, pero utiliza un orden de presentación m&aacute;s lógico que el alfabético e incluye material explicativo adicional.

2.2.1. Tópico

Un tópico es un recurso que actúa como sustituto para algún concepto; es el sistema de representación de ese concepto en el mapa de tópicos. La relación entre un tópico y su concepto se define como una relación de simbolización. La simbolización de un concepto permite asignar características de tópico al tópico que lo simboliza.

Cada tópico individual es una instancia de una o más clases de tópicos (también conocidos como tipos de tópicos) que pueden o no ser indicados explícitamente. El tipo de tópico por defecto es definido por el "tópico" concepto publicado.

2.2.1.1. Concepto

Un concepto es cualquier cosa sobre la que pueda hablarse o ser concebida por un ser humano. En el sentido más genérico, un concepto es cualquier cosa, con independencia de si existe o tiene otras características específicas, sobre la que puede afirmarse cualquier cosa con cualquier significado. En particular, es cualquier cosa sobre la que el autor de un mapa de tópicos elige razonar.

Para hablar sobre un concepto dentro del paradigma mapa de tópicos, ese concepto debe ser simbolizado mediante la creación de un tópico. Los conceptos son así el principio organizativo de los tópicos.

En un mapa de tópicos consistente cada concepto es representado por un único tópico. En un documento mapa de tópicos, por otro lado, múltiples tópicos pueden cosificar el mismo concepto (aunque preferiblemente de forma que puedan ser unidos en un solo tópico durante el procesamiento).

La mayoría de los conceptos existen fuera de los límites del sistema informático; no pueden ser direccionados directamente y sus identidades son, por lo tanto, no computables. Ejemplos de estos conceptos no-direccionables son William Shakespeare, la obra Hamlet y su edición de 1604-05, el personaje Hamlet, el concepto de venganza, la empresa Shakespeare y Cía, etc. La identidad de un concepto no-direccionable sólo puede ser establecida indirectamente, por ejemplo mediante el uso de un indicador de concepto.

Sin embargo, cualquier cosa puede ser tema de análisis en un mapa de tópicos, inclusive recursos dentro del sistema informático, que pueden direccionarse directamente. Los recursos considerados como conceptos se denominan conceptos direccionables. Un ejemplo de concepto direccionable sería esta especificación, considerado como un documento HTML.

2.2.1.2. Simbolización

El acto de crear un tópico se llama simbolización. Cuando algo se simboliza se convierte en el concepto del tópico así creado; cosificar algo es, por tanto, crear un tópico del cual ese algo es el concepto. La simbolización de un concepto permite asignar características de tópico al tópico que lo simboliza: en otras palabras, hace posible el análisis discursivo del concepto en los términos del paradigma de los mapas de tópicos.

La noción de simbolización se sitúa en el centro neurálgico del paradigma mapa de tópicos. El único medio por el cual es posible decir algo en un mapa de tópicos es crear un tópico y entonces asignarle características. Los tópicos son los que hacen a los conceptos "reales" para el sistema y son lo más cercano a lo que una máquina puede representar de lo que es "real" para humanos.

Dado que cualquier cosa puede ser un concepto, la simbolización puede ser aplicada también a objetos dentro del propio mapa de tópicos, como las asociaciones, nombres, y ocurrencias. (Para ejemplos de cómo puede hacerse sintácticamente, véase <association> y <occurrence> en la Sección 3. Documentación de la Sintaxis XTM). Esto hace posible tanto aplicar la potencia del paradigma mapa de tópicos a los propios mapas de tópicos como permitir múltiples niveles de la representación del conocimiento dentro del mismo mapa, inclusive el hacer afirmaciones acerca de afirmaciones.

2.2.1.3. Identidad del concepto

La identidad del concepto es el medio por el cual se puede establecer cual es el concepto que está siendo simbolizado por un determinado tópico. Cuando dos tópicos tienen la misma identidad del concepto, se considera que representan la misma la misma cosa y, por tanto, deben ser unidos. Debido a la necesidad de ser capaz de unir mapas tópicos —en definitiva, intercambiar sus semánticas— el paradigma mapa de tópicos profundiza bastante con la intención de hacer posible establecer la identidad de un tópico (y, así mismo, su concepto) tan sólidamente como sea posible.

La identidad del concepto puede establecerse de una de dos formas:

1. Direccionando el concepto directamente. Esto es posible sólo cuando el concepto sujeto es un recurso de información direccionable.
2. Indicando el concepto vía un indicador de concepto (véase abajo)

2.2.1.4. Indicador de concepto

Un indicador de concepto es un recurso mediante el que el autor de un mapa de tópicos intenta dar una indicación positiva y sin ambigüedades de la identidad de un concepto. Cuando dos tópicos utilizan el mismo recurso para indicar su concepto, se considera que representan la misma la misma cosa y, por tanto, deben ser unidos durante el procesamiento.

Dado que la identidad del concepto constituye la base para unir mapas de tópicos e intercambiar semántica, se anima a los autores a indicar siempre la identidad del concepto de sus tópicos de la forma más inequívoca posible, en particular mediante el uso de ontologías estándar expresadas como indicadores de concepto publicados.

Como el mismo concepto puede indicarse de varios modos, es posible que dos tópicos que cosifican el mismo concepto usen indicadores de concepto diferentes y que, por tanto, no se unan. Deben evitarse situaciones como ésta mediante el uso de un tercer tópico (en el mismo u otro documento mapa de tópicos) que establezca su identidad a través de ambos indicadores de concepto. Así, los mapas de tópicos se pueden utilizar para mediar entre ontologías.

2.2.1.5. Característica de tópico

Cualquier cosa que pueda afirmarse sobre un tópico en el paradigma mapa de tópicos se conoce como característica de ese tópico. Pueden ser características uno de los siguientes:

• un nombre de tópico,
• una ocurrencia de tópico, o
• un rol jugado por un tópico como miembro de una asociación

La asignación de tales características se considera válida dentro de un cierto alcance, o contexto.

2.2.1.6. Alcance

El alcance especifica la extensión de la validez de una asignación de característica de tópico. Establece el contexto en el que un nombre o una ocurrencia son asignados a un tópico dado, y el contexto en el que los tópicos están relacionados por asociaciones. Cada característica tiene un alcance, que se puede especificar bien explícitamente, como un conjunto de tópicos, o implícitamente, en cuyo caso se conoce como alcance no limitado. Las asignaciones hechas en el alcance no limitado son siempre válidas.

El alcance se considera para establecer un espacio de nombres para los nombres de base de los tópicos. Esto lleva a la limitación, impuesta por el paradigma mapa de tópicos, llamada restricción de denominación de tópico, de que los tópicos que tienen el mismo nombre base en el mismo alcance se refieren implícitamente al mismo concepto y, por tanto, deber unirse. A excepción de esta limitación, la interpretación del alcance de una característica y su efecto en el procesamiento se deja a la aplicación y no está limitada en forma alguna por esta especificación.

2.2.2. Nombre

Un tópico puede tener cero o más nombres, cada uno de los cuales es considerado válido dentro de un cierto alcance (que puede ser el alcance no limitado)

Cada nombre puede existir en múltiples formas. Un nombre tiene siempre exactamente una forma básica, conocida como nombre base, y puede, además, tener una o más variantes para su uso en contextos de procesamiento específico.

2.2.2.1. Nombre base

Un nombre base es la forma básica de un nombre de tópico; es siempre una cadena de caracteres. Cuando una aplicación elige utilizar un nombre de tópico particular para etiquetar un tópico, el nombre base proporciona la cadena de caracteres de uso para la aplicación a menos que exista una variante más pertinente en el contexto de procesamiento.

Los nombres base son conceptos para la restricción de denominación de nombres, que evita que un mapa de tópicos procesado contenga múltiples tópicos con el mismo nombre en el mismo alcance.

2.2.2.2. Variante de nombre

Una variante de nombre es una forma alternativa de un nombre base, optimizado para un propósito computacional particular, tal como su ordenación o presentación en pantalla. Puede ser cualquier clase de recurso, incluso una cadena de caracteres. Una aplicación escoge entre variantes de nombre evaluando sus parámetros.

2.2.2.3. Parámetros

Los parámetros son información, en forma de un conjunto de tópicos, que expresa el contexto apropiado de procesamiento de una variante de nombre. Habiendo seleccionado un particular nombre de tópico, una aplicación puede decidir examinar los parámetros de sus variantes (si las hay) para seleccionar la forma más conveniente de ese nombre.

2.2.3. Ocurrencia

Una ocurrencia es cualquier información considerada relevante para un concepto dado. Las ocurrencias constituyen uno de las tres clases de característica que pueden ser asignadas a un tópico y están, por tanto, gobernadas por el alcance. Cada ocurrencia individual es una instancia de una sola clase de ocurrencia (también conocida como tipo ocurrencia) que puede o no ser indicada explícitamente. El tipo ocurrencia por defecto está definido por el concepto publicado "ocurrencia".

Para ser expresado en un mapa de tópicos XTM, dichos ocurrencias deben ser recursos que pueden ser

1. direccionado mediante una referencia utilizando una URI (una "referencia de recurso", o
2. situado en el documento XTM como datos de carácter ("datos de recurso").

El último (datos de recurso) proporciona una forma útil de expresar una pieza corta de información acerca de un concepto (por ejemplo, la fecha de composición de una obra).

2.2.4. Asociación

Una asociación es una relación entre uno o más tópicos, cada uno de los cuales juega un rol como miembro de esa asociación. Los roles que un tópico juega en las asociaciones están entre las características que pueden serle asignadas y, por tanto, son gobernadas por el alcance. Cada asociación individual es una instancia de una sola clase de asociación (también conocida como tipo asociación) que puede o no ser indicada explícitamente. El tipo asociación por defecto está definido por el concepto publicado "asociación".

No hay direccionalidad inherente en una asociación. (Las asociaciones describen relaciones: Si A está relacionado con B, entonces B debe también estar relacionado con A. Está más relacionado con cuál es la clase de relación y que papeles son jugados por sus miembros. La cuestión de cómo marcar una relación es un problema de denominación, no de dirección.)

2.2.4.1. Miembro

Un miembro es un conjunto de tópicos que juegan un rol particular en una asociación.

2.2.4.2. Rol

El concepto de rol expresa la naturaleza de la participación de un tópico como miembro de una asociación.

2.2.4.3. Clase-Instancia

Clase-instancia es una clase de asociación que expresa las relaciones clase-instancia entre tópicos que juegan los roles de clase e instancia respectivamente. Los conceptos "clase-instancia", "clase", e "instancia" están todos definidos por indicadores de concepto publicados (PSIs) publicados en esta especificación.

2.2.4.4. Superclase-Subclase

Superclase-subclase es una clase de asociación que expresa las relaciones superclase-subclase entre tópicos que juegan los roles de superclase y subclase respectivamente. Los conceptos "superclase-subclase", "superclase", y "subclase" están todos definidos por indicadores de concepto publicados (PSIs) publicados en esta especificación.

2.2.5. Mapa de tópicos

Un mapa de tópicos es una colección de tópicos, asociaciones, y alcances (llamados colectivamente nodos del mapa de tópicos) que pueden existir en una de dos formas:

1. un formato de intercambio serializado (p.e. como un documento mapa de tópicos expresado en sintaxis XTM o alguna otra sintaxis), o
2. alguna forma de aplicación interna, como la que está limitada por los Requerimientos de Proceso XTM definidos en el Anexo F.

El propósito de un mapa de tópicos es transmitir el conocimiento contenido en recursos a través de una capa sobrepuesta, o mapa, de los propios recursos. Un mapa de tópicos capta los conceptos de los que tratan los recursos, y las relaciones entre conceptos, en una forma en que es independiente de la implementación.

2.2.5.1 Nodo de mapa de tópicos

Los nodos del mapa de tópicos son objetos en la representación interna de un mapa de tópicos del sistema) que representan tópicos, asociaciones y alcances.

2.2.5.2 Mapa de tópicos consistente

Un mapa de tópicos consistente es uno en el que existe un solo tópico por concepto y no hay posibilidad adicional de unir o suprimir duplicados, tal como se define en el Anexo F: Requerimientos de Proceso XTM.

2.2.5.3. Documento mapa de tópicos

Un documento mapa de tópicos es un documento que contiene uno o más mapas de tópicos de acuerdo a esta especificación. Puede serializarse con propósitos de almacenamiento o intercambio en una sintaxis dirigida por ésta o alguna otra especificación.

2.2.5.4. Documento XTM

Un documento XTM es un documento mapa de tópicos que está expresado en la sintaxis definida por esta especificación.

2.3. Conceptos Publicados

2.3.1. Introducción

Un concepto publicado es cualquier concepto para el que se ha puesto a disposición un indicador de concepto para su uso público y es accesible en línea vía un URI. Un indicador de concepto publicado es, por tanto, cualquier recurso que se ha publicado para  proporcionar una identificación positiva y sin ambigüedades de la identidad de un concepto con el propósito de facilitar el intercambio de mapas de tópicos y la unión.

2.3.2. Indicadores de Concepto Publicados Obligatorios XTM

Ciertos conceptos son necesarios, intrínsecamente, y, por lo tanto, se publican en especificación. Varias limitaciones impuestas por esta especificación son expresadas en términos de estos conceptos publicados, incluyendo la clase por defecto de tópicos, asociaciones, y ocurrencias, y la equivalencia entre el uso de <instanceOf> y una asociación del tipo clase-instancia en el alcance no limitado.

Los Indicadores de Concepto Publicados proporcionados por esta especificación como conceptos obligatorios XTM se identifican brevemente en esta sección. Las descripciones breves hechas aquí son referenciadas como indicadores de concepto por los elementos <topic> contenidos en el mapa de tópicos que se encuentra en el Anexo E: Indicadores de Concepto Publicados Básicos XTM 1.0.

tópico

El concepto central de tópico; la clase genérica a la cual todos los tópicos pertenecen a menos que se especifique otra cosa.

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

asociación

El concepto central de asociación; la clase genérica a la cual todas las asociaciones pertenecen a menos que se especifique otra cosa.

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

ocurrencia

El concepto central de ocurrencia; la clase genérica a la cual todas las ocurrencias pertenecen a menos que se especifique otra cosa.

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

relación clase-instancia

El concepto central de clase-instancia; la clase de asociación que representa relaciones clase-instancia entre tópicos, y que es semánticamente equivalente al uso de los subelementos <instanceOf>.

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

clase

El concepto central de clase; el papel de clase tal como es jugado por uno de los miembros de una asociación clase-instancia.

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

instancia

El concepto central de instancia; el papel de instancia tal como es jugado por uno de los miembros de una asociación clase-instancia.

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

relación superclase-subclase

El concepto central superclase-subclase; la clase de asociación que representa relaciones superclase-subclase entre tópicos.

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

superclase

El concepto central de superclase; el papel de superclase tal como es jugado por uno de los miembros de una asociación superclase-subclase.

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

subclase

El concepto central de subclase; el papel de subclase tal como es jugado por uno de los miembros de una asociación superclase-subclase.

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

Idoneidad para la ordenación

Idoneidad de un nombre de tópico para ser usado como una clave corta; de uso en los parámetros de las variantes de nombre.

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

Idoneidad para la visualización

Idoneidad de un nombre de tópico para su visualización; de uso en los parámetros de las variantes de nombre.

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

2.4. Unir

El término unir cubre dos procesos distintos:

1. El proceso de unir dos mapas de tópicos, bien como resultado de directrices <mergeMap> explícitas, bien por razones específicas de la aplicación.
2. El proceso de unir dos tópicos.

Las reglas que dirigen todas las formas de unión y la determinación de la identidad del concepto se especifican en su totalidad en el Anexo F: Requisitos de Proceso de XTM. Pueden describirse brevemente (y de forma incompleta) como sigue:

1. Cuando dos mapas de tópico se unen, cualquier tópico que la aplicación, a través de cualquier medio, determina que tienen el mismo concepto son unidos, y cualquier asociación duplicada se elimina.
2. Cuando dos tópicos se unen, el resultado es un solo tópico cuyas características son la unión de las características de los tópicos originales, con los duplicados eliminados.

Se considerará siempre que dos tópicos se refieren al mismo concepto si:

1. tienen uno o más indicadores de concepto en común,
2. cosifican el mismo concepto direccionable, o
3. tienen el mismo nombre base en el mismo alcance.

3. Documentación de la sintaxis XTM

3.1 Introducción a la sintaxis XTM

La sintaxis para serializar e intercambiar documentos mapa de tópicos conformes a esta especificación está descrita en la definición de tipo de documento XML (DTD XML) proporcionada en el Anexo D: Definición de Tipo de Documento XTM 1.0. Esta sección proporciona documentación para todos los elementos definidos en esa DTD.

A continuación se da una lista completa de los tipos de elementos XTM en el orden en el que se documentan:

• <topicRef>: referencia a un elemento tópico
• <subjectIndicatorRef>: referencia a un indicador de concepto
• <scope>: referencia al tópico(s) que determina el alcance
• <instanceOf>: Apunta a un tópico que representa una clase
• <topicMap>: elemento documento mapa de tópicos
• <topic>: elemento tópico
• <subjectIdentity>: concepto simbolizado por un tópico
• <baseName>: nombre base de un tópico
• <baseNameString>: recipiente de la cadena de caracteres del nombre base
• <variant>: formas alternativas del nombre base
• <variantName>: recipiente de la variante del nombre
• <parameters>: contexto de procesamiento para las variantes
• <association>: asociación de tópicos
• <member>: miembro en la asociación de tópicos
• <roleSpec>: Apunta a un tópico que actúa como rol en la asociación
• <occurrence>: recursos considerados como ocurrencia
• <resourceRef>: referencia a un recurso
• <resourceData>: recipiente de recursos de datos
• <mergeMap>: Unión con otro mapa de tópicos

3.2. Referencias a Tópicos e Indicadores de Concepto

3.2.1. Elemento <topicRef>

El elemento <topicRef> proporciona una referencia URI a un tópico. La diana de un enlace <topicRef> debe resolver un elemento <topic> de un documento <topicMap> que se ajusta a esta especificación XTM. El <topic> diana no es necesario que esté en el documento de origen.

Los elementos <topicRef> son idénticos a los elementos <subjectIndicatorRef>, excepto por la limitación adicional de que deben apuntar a elementos <topic>.

Se da en: <instanceOf>, <member>, <mergeMap>, <parameters>, <roleSpec>, <scope>, <subjectIdentity>

Modelo de contenido

<!ELEMENT topicRef  EMPTY >

El elemento <topicRef> no tiene contenido.

Atributos

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

El elemento <topicRef> tiene los atributos siguientes:

Nota: Veáse las secciones 5.2 y 5.4 de [XLINK] para la conformidad y el uso.

Ejemplos

Referencia un tópico con la ID "en" en el documento language.xtm (este es, de hecho, un concepto publicado para el idioma inglés):

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

Referencia un tópico con la ID "obra" que está físicamente localizado en el documento actual:

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

Para otros ejemplos, véase <scope>, <instanceOf>, <variant>, <association>, y <mergeMap>.

3.2.2. Elemento <subjectIndicatorRef>

El elemento <subjectIndicatorRef> proporciona una referencia URI a un recurso que actúa como un indicador de concepto.

Se da en: <instanceOf>, <member>, <mergeMap>, <parameters>, <roleSpec>, <scope>, <subjectIdentity>

Modelo de contenido

<!ELEMENT subjectIndicatorRef  EMPTY>

El elemento <subjectIndicatorRef> no tiene contenido.

Atributos

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

El elemento <subjectIndicatorRef> tiene los atributos siguientes:

Nota: Veáse las secciones 5.2 y 5.4 de [XLINK] para la conformidad y el uso.

Ejemplos

Referencia a un indicador de concepto publicado:

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

Referencia a un recurso (ficticio) que indica un concepto menos formalmente:

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

Para otros ejemplos, véase <scope>, <instanceOf>, <subjectIdentity>.

Para ejemplos de cómo utilizar <subjectIndicatorRef>, para cosificar constructos de mapa de tópicos, véase <association> y <occurrence>.

3.3. Alcance y Contexto

3.3.1. Elemento <scope>

El elemento <scope> está constituido por uno o más elementos <topicRef>, <resourceRef>, o <subjectIndicatorRef>. La unión de los conceptos correspondientes a estos elementos especifica el contexto en el que la asignación de la característica de tópico se considera válida.

Una declaración de una característica de tópico es válida sólo en un alcance. Cuando una declaración de característica de tópico no especifica un alcance, es válida en el alcance no limitado.

Se da en: <baseName>, <occurrence>, <association>

Modelo de contenido

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

<topicRef>

Cada elemento hijo repetible <topicRef> referencia a un elemento <tópico> ("topico de alcance") cuyo concepto contribuye al alcance.

<resourceRef>

Cada elemento hijo repetible <resourceRef> referencia a un recurso que contribuye al alcance.

<subjectIndicatorRef>

Cada elemento hijo repetible <subjectIndicatorRef> referencia a un recurso que indica la identidad del concepto que contribuye al alcance.

Atributos

<!ATTLIST scope
   id              ID        #IMPLIED
>

El elemento <scope> tiene los atributos siguientes:

Ejemplos

Define un alcance consistente en el concepto "Inglés" utilizando un concepto publicado:

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

Define un alcance con los tópicos "tragedia" y "teatro" en el documento actual:

<scope>
  <topicRef xlink:href="#tragedia"/>
  <topicRef xlink:href="#teatro"/>
</scope>

Para otros ejemplos, véase <baseName>.

3.4. Clases e Instancias

3.4.1 Elemento <instanceOf>

El elemento <instanceOf> especifica la clase a la que su padre pertenece, vía un elemento hijo <topicRef> o <subjectIndicatorRef>.

Para las limitaciones en el uso de <instanceOf>, véase la descripción de los tipos de elementos que pueden ser su padre: <topic>, <occurrence>, and <association>.

El elemento <instanceOf> es un atajo sintáctico para una asociación de un tipo especial definido por el concepto publicado clase-instancia.

Se da en: <topic>, <occurrence>, <association>

Modelo de contenido

<!ELEMENT instanceOf  ( topicRef | subjectIndicatorRef ) >

<topicRef>

Cada elemento hijo repetible <topicRef> referencia a un elemento <tópico> que simboliza una clase de concepto.

<subjectIndicatorRef>

Cada elemento hijo repetible <subjectIndicatorRef> referencia a un recurso que indica la identidad de una clase de concepto.

Atributos

<!ATTLIST instanceOf
   id              ID        #IMPLIED
>

El elemento <instanceOf> tiene el atributo siguiente:

Ejemplos

Declara que el tópico con la ID "hamlet" es una instancia del tipo de tópico cuya es ID "obra":

<topic id="obra">
 </topic>

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

Referencia a un indicador de concepto para establecer el concepto del cual un tópico es una instancia:

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

Referencia a un concepto publicado en una ontología pública para establecer el concepto del cual un tópico es una instancia:

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

Para otros ejemplos, véase <topic>, <association>, y <occurrence>.

3.5. Mapa de tópicos

3.5.1. Elemento <topicMap>

El elemento <topicMap> es el padre de todos los elementos <topic>, <association> y <mergeMap> en el documento mapa de tópicos.

El elemento <topicMap> es el elemento raíz desde el que se realiza el reconocimiento sintáctico del mapa de tópicos. El elemento <topicMap> puede ser la raíz de un documento que contiene sólo un mapa de tópicos (p. ej. cuando es el elemento documento), o puede ser la raíz de una subrama dentro de un documento XML que contiene otra información distinta al propio mapa de tópicos. En el último caso, sólo se tiene en cuenta la rama que comienza con el elemento <topicMap> para el reconocimiento y la conformidad sintácticos del mapa de tópicos.

Modelo de contenido

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

<topic>

Cada elemento hijo opcional y repetible <topic> simboliza un solo concepto.

<association>

Cada elemento hijo opcional y repetible <association> especifica una relación entre tópicos.

<mergeMap>

Cada elemento hijo opcional y repetible <mergeMap> provoca que su mapa de tópicos padre sea unido a otro mapa de tópicos.

Atributos

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

El elemento <topicMap> tiene los atributos siguientes:

Notas: Veáse las secciones 5.2 y 5.4 de [XLINK] para la conformidad y el uso.           Veáse la sección 3 de [XML Base] para los detalles sobre el uso del atributo xml:base.

Ejemplos

Un elemento <topicMap> incluido en un documento XML:

...
<topicMap>

 <!-- los tópicos, las asociaciones, y la directivas de unión de mapa
      van aquí............................................................-->

</topicMap>
 ... 

Un elemento <topicMap> que constituye un documento completo:

<?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/'>

 <!-- los tópicos, las asociaciones, y la directivas de unión de mapa
      van aquí............................................................-->

</topicMap>

3.6. Tópicos y Conceptos

3.6.1 Elemento <topic>

El elemento <topic> especifica las características nombre y ocurrencia de un solo tópico. Tiene un identificador único, y capacidad para indicar la clase(s) de la que es una ocurrencia y la identidad del concepto que simboliza. Por definición, un tópico simboliza sólo un concepto. Cada tópico se pretende que esté organizado alrededor de exactamente un concepto, incluso si ese concepto sujeto es definido sólo implícitamente. Durante el procesamiento de XTM, los tópicos con conceptos idénticos se unirán según las reglas especificadas en el Anexo F: Requisitos de Procesamiento XTM. Sin embargo, un documento mapa de tópicos puede contener múltiples elementos topic para cosificar el mismo concepto. Después del procesamiento habrá un sólo tópico para cada concepto; sus características serán la unión de las características de todos los tópicos que cosifican ese concepto. (Para la discusión adicional del proceso de unión, véase la sección 2.4. Unir)

La clase(s) de la que el tópico es una instancia se indica vía elemento(s) hijo(s) <instanceOf>, cada uno de los cuales direcciona un tópico o un indicador de concepto. Si no hay ningún hijo <instanceOf>, la clase del tópico pertenece por defecto a la clase definida por el concepto publicado "tópico".

Un elemento <topic> especifica cero o más nombres y cero o más ocurrencias que son pertinentes a su concepto. Los nombres son declarados por medio de elementos hijos <baseName>. Las ocurrencias son especificadas por medio de elementos hijos <occurrence>.

Se da en: <topicMap>

Modelo de contenido

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

<instanceOf>

Cada elemento hijo opcional y repetible <instanceOf> especifica una clase de la cual este tópico es una instancia.

<subjectIdentity>

El elemento hijo opcional <subjectIdentity> especifica la identidad de concepto de este tópico.

<baseName>

Cada elemento hijo opcional y repetible <baseName> especifica una característica nombre de este tópico.

<occurrence>

Cada elemento hijo opcional y repetible <occurrence> especifica recursos de información que son pertinentes a este tópico.

Atributos

 <!ATTLIST topic
   id              ID        #REQUIRED
>

El elemento <topic> tiene el atributo siguiente:

Ejemplo

El tópico cuya ID es "hamlet" es una instancia del tipo de tópico cuya ID es "obra":

<topic id="hamlet">
 <instanceOf>
   <topicRef xlink:href="#obra"/>
  </instanceOf>
 <!-- los nombres base y las ocurrencias van aquí..........................-->
</topic>

Para ejemplos adicionales, véase <subjectIdentity>, <baseName>, <variant>, <association>, y <occurrence>.

3.6.2. Elemento <subjectIdentity>

El elemento <subjectIdentity> especifica el concepto que es simbolizado por un tópico, vía <resourceRef>, <subjectIndicatorRef>, o elementos hijos <topicRef>.

Cuando un tópico tiene un concepto direccionable, el concepto puede direccionarse directamente vía un elemento <resourceRef>. En ese caso, es el propio recurso el que es considerado el concepto del tópico, no lo que el recurso signifique o indique. Sólo puede haber un recurso de este tipo por tópico.

Los recursos pueden ser también indicadores de concepto, en comparación con los conceptos en y de sí mismos. Los recursos se utilizan para indicar conceptos vía elementos <subjectIndicatorRef>, de los que puede haber más de uno por tópico.

Un tópico puede indicar también que tiene el mismo concepto que otro tópico direccionando ese tópico vía un elemento <topicRef>. Puede haber múltiples de tales elementos, cada uno de los cuales provoca que se produzca la unión de tópicos.

Se da en: <topic>

Modelo de contenido

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

<resourceRef>

El elemento opcional <resourceRef> referencia un concepto direccionable.

<topicRef>

Cada elemento hijo opcional y repetible <topicRef> referencia a un elemento <topic> que comparte el mismo concepto.

<subjectIndicatorRef>

Cada elemento hijo opcional y repetible <subjectIndicatorRef> referencia a un indicador de concepto.

Atributos

<!ATTLIST subjectIdentity
   id              ID        #IMPLIED
>

El elemento <subjectIdentity> tiene el atributo siguiente:

Ejemplos

En el Mapa de tópicos 1: establece la identidad referenciando un indicador de concepto publicado (aquí, el país Dinamarca, tal como es definido por los PSI's de Topicmaps.Org basados en la ISO 3166):

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

En el Mapa de tópicos 2: establece la identidad referenciando una ontología más informal (aquí, la versión en línea del CIA World Factbook):

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

En el Mapa de tópicos 3: declara un tópico que expresa un mapeo entre las ontologías ISO y CIA y produce una unión correcta:

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

3.7. Nombres de Tópico

3.7.1. Elemento <baseName>

El elemento <baseName> especifica un nombre de tópico. Un nombre de tópico es representado por una cadena: el contenido del elemento hijo <baseNameString> de <baseName>. El contexto dentro del cual la asignación de un nombre a un tópico es válida puede expresarse utilizando un elemento hijo <scope>. Si ninguno de ellos está presente, el alcance no está limitado y el nombre siempre es válido. Un tópico puede tener múltiples nombres base en uno o múltiples alcances.

La diferenciación del lenguaje natural entre nombres base puede ser especificada mediante un elemento hijo <scope>. (Se pueden encontrar Conceptos Publicados adecuados para definir estos alcances en Tópicos de Idioma XTM, un mapa de tópicos mantenido por TopicMaps.Org que proporciona conceptos publicados para lenguajes naturales. Véase Anexo E: XTM 1.0 Core Published Concepto Indicators).

Los nombres base están sujetos a la restricción de denominación de tópico de que dos tópicos con el mismo nombre base en el mismo alcance implícitamente cosifican el mismo concepto y por tanto deben unirse.

Las formas alternativas del nombre de tópico, optimizadas para propósitos computacionales como ordenar, buscar, y visualización, son especificadas mediante elementos <variant>.

Se da en: <topic>

Modelo de contenido

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

<scope>

El elemento hijo opcional <scope> especifica el contexto en el que este nombre base es válido.

<baseNameString>

El elemento hijo único obligatorio <baseNameString> proporciona la cadena de caracteres que es el nombre base del tópico.

<variant>

El elemento hijo opcional y repetible <variant> proporciona formas alternativas del nombre base.

Atributos

<!ATTLIST baseName
   id              ID        #IMPLIED
>

El elemento <baseName> tiene el atributo siguiente:

Ejemplos

Ejemplo sencillo:

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

Tópico con múltiples nombres en idiomas diferentes, diferenciado por el alcance (se asume la existencia de tópicos con las ID "en" y "da" que cosifican los conceptos "English" y "Danish" respectivamente):

<topic id="Dinamarca">

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

Utilización del alcance para evitar uniones indeseadas debido a la restricción de denominación de tópico (si los dos usos del nombre "Hamlet" no se sitúan en alcances diferentes, estos dos tópicos se unirían):

<topic id="hamlet">
 <baseName>
   <baseNameString>La tragedia de Hamlet, Príncipe de Dinamarca</baseNameString>
 </baseName>
  <baseName>
   <scope><topicRef xlink:href="#obra"/></scope>
   <baseNameString>Hamlet</baseNameString>
 </baseName>
 </topic>

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

Da múltiples nombres a un tipo asociación para que las asociaciones de este tipo puedan ser etiquetadas dependiendo del punto de vista diferente desde el que se observen. El tópico en este ejemplo tiene el nombre predefinido "escrito por" (en el alcance no limitado); sin embargo, en el contexto "autor" (por ejemplo cuando, en una aplicación, lo que se considera como el "actual tópico" juega el papel de "autor"), la cadena de caracteres "autor de" parece proporcionar un nombre base más apropiado:

<topic id="escrito por">
  <baseName>
     <baseNameString>escrito por</baseNameString>
  </baseName>
  <baseName>
     <scope><topicRef xlink:href="#autor"/></scope>
     <baseNameString>autor de</baseNameString>
  </baseName>
</topic>

3.7.2. Elemento <baseNameString>

El elemento <baseNameString> es una cadena de caracteres que representa el nombre base de su pariente ancestro <topic>.

Se da en: <baseName>

Modelo de contenido

<!ELEMENT baseNameString  ( #PCDATA ) >

El elemento <baseNameString> contiene #PCDATA; solo puede contener datos de carácter.

Atributos

<!ATTLIST baseNameString
   id              ID        #IMPLIED
>

El elemento <baseNameString> tiene el atributo siguiente:

Ejemplo

Véase el elemento <baseName>.

3.7.3. Elemento <variant>

El elemento <variant> es una forma alternativa del nombre base de un tópico apropiado para un contexto de procesamiento especificado por el elemento hijo <parameters> de la variante. Entre sus contextos pueden estar la ordenación y la visualización.

Cada elemento hijo <variantName> en la estructura recursiva proporciona una única forma alternativa del nombre base; el contexto de procesamiento en el que esta forma se considera apropiada se define por la unión de todos los parámetros a este nivel y los niveles superiores de la estructura recursiva (en otras palabras, los parámetros son heredados a lo largo del árbol). Para una completa descripción, véase "Procesamiento de las variantes del alcance" en el Anexo F: Requisitos de Procesamiento XTM.

Una variante de nombre cuyos parámetros incluyen los conceptos publicados "visualización" u "ordenación" (véase la la Sección 2.3.2. Indicadores de Concepto Publicados Obligatorios XTM) es semánticamente equivalente a mostrar los nombres (display names) y ordenar los nombres (sort names), respectivamente, tal como está definido en ISO 13250.

Se da en: <baseName>

Modelo de contenido

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

<parameters>

El elemento hijo único obligatorio <parameters> especifica un contexto de procesamiento adicional para su elemento padre <variant>.

<variantName>

El elemento hijo opcional <variantName> proporciona una forma alternativa del nombre base.

<variant>

Cada elemento hijo opcional y repetible <variant> especifica parámetros adicionales y variantes de nombre, dentro del contexto de los parámetros declarados por su elemento padre <variant>.

Atributos

<!ATTLIST variant id ID #IMPLIED >

El elemento <variant> tiene el atributo siguiente:

Ejemplos

Especifica una forma alternativa del nombre base con fines de ordenación:

 <topic id="shakespeare">
  <baseName>
    <baseNameString>William Shakespeare</baseNameString>
    <!-forma para ordenar (nombre de ordenación) -->
    <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>

El ejemplo siguiente muestra variantes del nombre base "Hamlet", inclusive formas alternativas para la presentación visual y sonora. El subárbol de variante para "display" ilustra cómo se utiliza el anidado de variantes, y cómo los parámetros son "acumulados" conforme se desciende a través de la estructura:

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

    <!-- formas alternativas de visualización (nombre de visualización)-->
    <variant>
      <parameters><topicRef xlink:href="#visualización"/></parameters>

      <!-- subárbol de variante para icono -->
      <variant>
        <parameters><topicRef xlink:href="#icono"/></parameters>
        <!-- subárbol de variante para grande -->
        <variant>
          <parameters><topicRef xlink:href="# grande"/></parameters>
          <variantName>
            <!-- parámetros efectivos = visualización + icono + grande -->
            <resourceRef xlink:href="img/hamlet64x64.png" />
          </variantName>
        </variant>
        <!-- subárbol de variante para pequeño -->
        <variant>
          <parameters><topicRef xlink:href="# pequeño "/></parameters>
          <variantName>
            <!-- parámetros efectivos = visualización + icono + pequeño -->
            <resourceRef xlink:href="img/hamlet16x16.png" />
          </variantName>
        </variant>
      </variant>

      <!-- subárbol de variante para pantalla completa -->
      <variant>
        <parameters><topicRef xlink:href="# pantalla completa"/></parameters>
        <!-- subárbol de variante para VGA -->
        <variant>
          <parameters><topicRef xlink:href="#vga"/></parameters>
          <variantName>
            <!-- parámetros efectivos = visualización + pantalla completa + vga -->
            <resourceRef xlink:href="img/hamlet640x480.png" />
          </variantName>
        </variant>
        <!-- subárbol de variante para SVGA -->
        <variant>
          <parameters><topicRef xlink:href="#svga"/></parameters>
          <variantName>
            <!-- parámetros efectivos = visualización + pantalla completa + svga -->
            <resourceRef xlink:href="img/hamlet800x600.png" />
          </variantName>
        </variant>
      </variant>

    </variant>

    <!-- formas alternativa para reproducción sonora -->
    <variant>
      <parameters><topicRef xlink:href="#audible"/></parameters>
      <variantName>
            <!-- effective parameters = audible -->
        <resourceRef xlink:href="au/hamlet.au"/>
      </variantName>
    </variant>

  </baseName>
</topic>

3.7.4. Elemento <variantName>

El elemento <variantName> proporciona el recurso que va a utilizarse como una variante de un nombre base. El recurso puede ser referenciado mediante un elemento <resourceRef> o puede incluirse directamente como un elemento <resourceData>.

Ocurre en: <variant>

Modelo de contenido

<!ELEMENT variantName ( resourceRef | resourceData )>

<resourceRef>

El elemento hijo <resourceRef> referencia a un recurso que proporciona la variante de nombre.

<resourceData>

El elemento hijo <resourceData> es el recurso que proporciona la variante de nombre.

Atributos

<!ATTLIST variantName id ID #IMPLIED >

El elemento <variantName> tiene el atributo siguiente:

Ejemplo

Véase el elemento <variant>.

3.7.5. Elemento <parameters>

El elemento <parameters> consiste en uno o más elementos <topicRef> o <subjectIndicatorRef>. La unión de los conceptos correspondientes a estos elementos especifica un contexto adicional de procesamiento en el que las variantes de nombre en el subárbol de variantes se consideran apropiadas.

Ocurre en: <variant>

Modelo de contenido

<!ELEMENT parameters ( topicRef | subjectIndicatorRef )+ >

<topicRef>

El elemento hijo repetible <topicRef> referencia a un elemento <topic> que indica el contexto de procesamiento del elemento padre <variant>.

<subjectIndicatorRef>

El elemento repetible <subjectIndicatorRef> referencia a un recurso que indica el contexto de procesamiento del elemento padre <variant>.

Atributos

<!ATTLIST parameters id ID #IMPLIED >

 El elemento <parameters> tiene el atributo siguiente:

Ejemplo

Véase el elemento <variant>.

3.8. Asociaciones y Miembros

3.8.1. Elemento <association>

El elemento <association> afirma una relación entre tópicos que juegan un rol como miembros de la asociación.

La clase a la que una <association> pertenece es especificada por un elemento hijo <instanceOf>. Si este elemento no está presente, la clase de asociación por defecto es el concepto publicado "asociación".

El contexto en el cual la afirmación hecha por la asociación es válida puede ser expresado utilizando un elemento hijo <scope>. Si no existe, el alcance es libre (no está limitado) y la asociación es válida siempre.

Se da en: <topicMap>

Modelo de contenido

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

<instanceOf>

El elemento hijo opcional <instanceOf> especifica la clase a la que pertenece esta asociación.

<scope>

El elemento hijo opcional <scope> especifica el contexto en el que la afirmación hecha por la asociación es válida.

<member>

El elemento obligatorio y repetible <member> especifica los tópicos que juegan roles en la asociación.

Atributos

<!ATTLIST association id ID #IMPLIED >

El elemento <association> tiene el atributo siguiente:

Ejemplos

Aquí existe una asociación del tipo "escrito-por" entre el tópico "Shakespeare" (jugando el rol de "autor") y el tópico "hamlet" (jugando el papel de "obra"). Es decir, [la obra] Hamlet fue escrita por [el autor] Shakespeare (o [el autor] Shakespeare escribió [la obra] Hamlet).

<association id="ha-escrito-Hamlet">
 <instanceOf>
  <topicRef xlink:href="# escrito-por "/>
 </instanceOf>
 <member>
  <roleSpec>
   <topicRef xlink:href="#autor"/>
  </roleSpec>
   <topicRef xlink:href="#shakespeare"/>
  </member>
  <member>
   <roleSpec>
    <topicRef xlink:href="#obra"/>
   </roleSpec>
    <topicRef xlink:href="#hamlet"/>
  </member>
</association>

Simboliza la asociación precedente para poder asignarle características:

<topic id="topico-ha-escrito-Hamlet">
 <subjectIdentity>
  <subjectIndicatorRef xlink:href="#ha-escrito-Hamlet" />
 </subjectIdentity>
 <baseName>
  <baseNameString>Shakespeare es el autor de Hamlet </baseNameString>
 </baseName>
 <!-- aquí pueden venir ocurrencias -->
</topic>

Declara la relación clase-instancia entre "hamlet" y "obra" utilizando una asociación, en vez de un elemento <instanceOf> (esto es semánticamente equivalente al primer ejemplo expuesto en <instanceOf>, arriba):

<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="#obra"/>
 </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="obra">
...
</topic>

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

3.8.2. Elemento <member>

El elemento <member> especifica todos los tópicos que juegan un papel dado en una asociación. El elemento <roleSpec> especifica el rol jugado por estos tópicos.

Se da en: <association>

Modelo de contenido

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

<roleSpec>

El elemento hijo opcional <roleSpec> especifica el papel jugado en esta asociación por ese miembro.

<topicRef>

Cada elemento hijo repetible <topicRef> referencia a un tópico que juega el rol especificado.

<resourceRef>

Cada elemento hijo repetible <resourceRef> referencia a un recurso que juega el rol especificado.

<subjectIndicatorRef>

Cada elemento repetible <subjectIndicatorRef> referencia a un indicador de concepto para un concepto que juega el rol especificado.

Atributos

<!ATTLIST member id ID #IMPLIED >

El elemento <member> tiene el atributo siguiente:

Ejemplo

Véase el elemento <association>.

3.8.3. Elemento <roleSpec>

El elemento <roleSpec> especifica el papel jugado por un miembro en una asociación.

Se da en: <member>

Modelo de contenido

<!ELEMENT roleSpec ( topicRef | subjectIndicatorRef ) >

<topicRef>

El elemento hijo <topicRef> referencia a un tópico que simboliza un rol en una asociación.

<subjectIndicatorRef>

El elemento hijo <subjectIndicatorRef> referencia a un indicador de concepto para un rol en una asociación.

Atributos

<!ATTLIST roleSpec id ID #IMPLIED >

El elemento <roleSpec> tiene el atributo siguiente:

Ejemplo

Véase el elemento <association>.

3.9. Ocurrencias y Recursos

3.9.1. Elemento <occurrence>

El elemento <occurrence> especifica un recurso que proporciona información pertinente a un tópico.

La clase de la que ocurrencia es una instancia se indica vía el elemento hijo <instanceOf>. Si este elemento no está presente, la clase de ocurrencia tipo por defecto viene definida por el concepto publicado "ocurrencia".

El contexto en el que la ocurrencia es válida puede expresarse utilizando un elemento hijo <scope>. Si no hay presente ninguno, el alcance es libre y la ocurrencia es válida siempre.

Se da en: <topic>

Modelo de contenido

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

<instanceOf>

El elemento hijo opcional <instanceOf> especifica la clase de la cual el tópico ocurrencia es una instancia.

<scope>

El elemento hijo opcional <scope> especifica el contexto en el que el recurso es pertinente al tópico.

<resourceRef>

El elemento hijo <resourceRef> referencia a un recurso que es una ocurrencia del tópico.

<resourceData>

El elemento hijo <resourceData> es el recurso que es una ocurrencia del tópico.

Atributos

<!ATTLIST occurrence
   id              ID        #IMPLIED
>

El elemento <occurrence> tiene el atributo siguiente:

Ejemplos

El tópico cuya ID es "hamlet" tiene una ocurrencia del tipo "fecha-de-creación" cuyo contenido es la cadena "1600-01", y una ocurrencia de tipo "versión-xml" en la URL mostrada:

<topic id="hamlet">
  <occurrence>
    <instanceOf>
      <topicRef xlink:href="# fecha-de-creación"/>
    </instanceOf>
    <resourceData>1600-01</resourceData>
  </occurrence>
  <occurrence id="hamlet-en-xml">
    <instanceOf>
      <topicRef xlink:href="#versión-xml "/>
    </instanceOf>
    <resourceRef
      xlink:href="http://www.csclub.uwaterloo.ca/u/relander/XML/hamlet.xml"/>
  </occurrence>
</topic>

Simboliza una de las ocurrencias anteriores para poder asignarle características:

<topic id="tópico-hamlet-en-xml">
  <subjectIdentity>
    <subjectIndicatorRef xlink:href="#hamlet-en-xml"/>
  </subjectIdentity>
  <baseName>
    <baseNameString> versión XML de Hamlet de Jon Bosak </baseNameString>
  </baseName>
  <!-- las ocurrencias pueden ir aquí (p. ej. comentarios sobre la versión XML 
        de Hamlet)                                                        -->
</topic>

3.9.2. Elemento <resourceRef>

El elemento <resourceRef> proporciona una referencia URI a un recurso.

Los recursos pueden referenciarse por una de las siguientes razones:

1. como ocurrencias de tópicos (en elementos <occurrence>)
2. como conceptos direccionables (en elementos <member>, <mergeMap>, <scope> y <subjectIdentity>), y
3. como variantes de nombre de tópicos (en elementos <variantName>)

Se da en: <member>, <mergeMap>, <occurrence>, <scope>, <subjectIdentity>, <variantName>

Modelo de contenido

<!ELEMENT resourceRef  EMPTY >

El elemento <resourceRef> no tiene contenido.

Atributos

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

El elemento <resourceRef> tiene los atributos siguientes:

Nota: Veánse las secciones 5.2 y 5.4 de [XLINK] para la conformidad y el uso.

Ejemplo

Véanse los elementos <variant>, <occurrence>, y <mergeMap>.

3.9.3. Elemento <resourceData>

El elemento <resourceData> contiene información en forma de los datos de carácter, que pueden ser:

1. una ocurrencia de un tópico, o
2. una forma variante de un nombre base

Ocurre en: <occurrence>, <variantName>

Modelo de contenido

<!ELEMENT resourceData  ( #PCDATA ) >

El elemento <resourceData> se declara #PCDATA, lo que significa que sólo puede contener datos de carácter.

Atributos

<!ATTLIST resourceData
   id              ID        #IMPLIED
>

El elemento <resourceData> tiene el atributo siguiente:

Ejemplo

Véanse los elementos <variant> y <occurrence>.

3.10. Unir

3.10.1. Elemento <mergeMap>

Un elemento <mergeMap> referencia un elemento <topicMap> externo a través de un atributo xlink:href que contiene un URI. Es una directiva para unir el mapa de tópicos que lo contiene y el mapa de tópicos referenciado de acuerdo a las reglas especificadas en el Anexo F: Requisitos de Procesamiento XTM.

Los hijos de <mergeMap> indican los tópicos que deberán añadirse a los alcances de todas características con origen en el mapa de tópicos referenciado. (La razón para modificar los alcances de las características unidas puede ser evitar la unión de tópicos teniendo en cuenta la restricción de denominación de tópicos, o para distinguir entre características en función de su mapa de tópicos de origen).

Ocurre en: <topicMap>

Modelo de contenido

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

<topicRef>

El elemento hijo opcional y repetible <topicRef> referencia a un tópico cuyo concepto será añadido al alcance de todas características con origen en el mapa de tópicos referenciado.

<resourceRef>

El elemento hijo opcional y repetible <resourceRef> referencia a un concepto direccionable será añadido al alcance de todas características con origen en el mapa de tópicos referenciado.

<subjectIndicatorRef>

El elemento hijo opcional y repetible <subjectIndicatorRef> referencia a un indicador de concepto cuyo concepto será añadido al alcance de todas características con origen en el mapa de tópicos referenciado.

Atributos

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

El elemento <mergeMap> tiene los atributos siguientes:

Nota: Veáse las secciones 5.2 y 5.4 de [XLINK] para la conformidad y el uso.

Ejemplos

Une el mapa de tópicos "obras.xtm" con el actual mapa de tópicos, agregando los tópicos "shakespeare" y "drama" (en el mapa de tópicos actual) a los alcances de todas las características con origen en el mapa de tópicos "obras.xtm":

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

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

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

Une el mapa de tópicos "biografía.xtm"con el mapa de tópicos actual, agregando el propio recurso (como un concepto direccionable) a los alcances de todas características con origen en el mapa de tópicos "biografía.xtm". Esta técnica permite que un autor use un mapa de tópicos como un concepto, para proporcionar un alcance a sus propios tópicos en el resultado de la unión:

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

4. Conformidad

Esta sección expone las condiciones bajo las que puede asegurarse con exactitud qué documentos y aplicaciones son conformes, es decir, se adecúan a la Especificación XTM.

Un documento o aplicación son conformes a la Especificación XTM sólo si se satisfacen todos los criterios de conformidad siguientes:

1. observa las condiciones obligatorias ("tiene que" y "debe"), y
2. para cualquier condición opcional ("podrá"; y "puede") que observe, lo hace en la forma prescrita.

Estos criterios de conformidad deben aplicarse en cualquier programa de certificación de conformidad de documentos y aplicaciones a la Especificación XTM, y en el desarrollo de series de prueba y otros instrumentos para medir e informar la conformidad de documentos y aplicaciones para la que se asegure dicha conformidad.

4.1. Vocabulario de Conformidad XTM

En esta especificación, las palabras clave "DEBE", "NO DEBE", "REQUERIDO", "DEBERÁ", "NO DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" deberán ser interpretados tal como se describe en RFC 2119 (véase [RFC 2119]). Sin embargo, en aras de la legibilidad, estas palabras no aparecen con todas las letras en mayúscula en esta especificación.

4.2. Dependencias de Procesamiento de XTM.

El procesamiento de XTM depende de [XML], [XML Names], [XLink], [XML Base], y [RFC 2396] (actualizado por [RFC 2732]).

4.3. El espacio de nombres XTM

La referencia URI usada como "nombre de espacio de nombre" (en el sentido especificado por la Recomendación para Espacios de nombre en XML del W3C [XML Names]) que identifica esta especificación de XTM es:

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

Las aplicaciones que deseen utilizar el procesamiento orientado al espacio de nombres del W3C para documentos conformes a esta especificación XTM deben asegurarse de que el nombre del espacio de nombre W3C es la cadena de caracteres URI anterior.

Esta especificación se reserva el uso de cualquier cadena de caracteres que empareje (('X'|'x') ('T'|'t') ('M'|'m')) para uso de esta especificación XTM y cualesquiera especificaciones relacionadas producidas por TopicMaps.Org.

4.4. Conformidad del Documento XTM

Un documento mapa de tópicos es conforme a la Especificación XTM 1.0 si y sólo si se satisfacen todas las condiciones siguientes, además de las condiciones indicadas anteriormente en 4.1. Vocabulario de Conformidad XTM:

• El documento es un documento XML que es conforme a la Recomendación XML 1.0 del W3C, ediciones posteriores, o Recomendación XML del W3C posterior, en la medida en que como tales no invaliden documentos XML existentes que son conformes a XTM.
• El documento contiene por lo menos un elemento <topicMap>.
• Cada elemento <topicMap> contenido en el documento es conforme a las limitaciones sintáticas impuestas sobre los elementos <topicMap> por la DTD XTM 1.0 especificada por esta Especificación.
• No hay elementos ni atributos contenidos en cualquiera de los elementos <topicMap> que no esté declarado explícitamente por la DTD XTM 1.0 especificada por esta Especificación. Un elemento <topicMap> es no-conforme si contiene elementos o atributos de cualquier otro "Espacio de nombres XML" a cualquier nivel recursivo de contenido de elemento.
• Todos las limitaciones sintácticas y otras especificadas por la Especificación XTM 1.0 se indican en cada uno de los elementos <topicMap> contenidos en el documento. Cuando cada elemento <topicMap> se procesa tal y como se define y describe en el Anexo F: Requisitos de Procesamiento XTM, no deben producirse Informes de Errores XTM.

El marcado XTM existente en un documento XML fuera de un elemento <topicMap> no está definido por esta especificación.

4.5. Conformidad de la Aplicación XTM

Una aplicación XTM es cualquier módulo de software que:

• interpreta un elemento <topicMap>, produciendo un mapa de tópicos procesado tal y como se define y describe en el Anexo F: Requisitos de Procesamiento XTM.

Una aplicación XTM es conforme a la Especificación XTM 1.0 si y sólo si se satisfacen todas las condiciones siguientes:

• Todas las limitaciones especificadas en Anexo F: Requisitos de Procesamiento XTM con respecto a la gestión de cada elemento y atributo XTM son manejadas por la aplicación XTM.
• Todos los Errores XTM que deben informarse se detectan, y la aplicación XTM es capaz de informar de todos ellos.
• Todas Reglas de Unión y otras Reglas especificadas en el Anexo F: Requisitos de Procesamiento XTM son manejadas por la aplicación de XTM.

Anexos

Anexo A: Referencias (Informativo)

Las siguientes referencias son especificaciones de las que este documento deriva, está relacionado, es dependiente o proporciona información sobre él:

[ISO13250]

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

[XML]

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

[XLink]

XML Linking Language (XLink) Version 1.0., Steve DeRose, Eve Maler, David Orchard, Ben Trafford, editors. World Wide Web Consortium, W3C Candidate Recommendation 3 July 2000. Véase: http://www.w3.org/TR/xlink

El procesamiento de XLink depende de [XML], [XML Names], [XML Base], and [IETF RFC 2396].

[XML Base]

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

[XML Names]

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

[RFC 1738]

Uniform Resource Locators (URL), IETF (Internet Engineering Task Force) RFC 1738, December 1994. Véase: http://www.ietf.org/rfc/rfc1738.txt

[RFC 2119]

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

[RFC 2141]

URN Syntax, IETF (Internet Engineering Task Force) RFC 2141, R. Moats, May 1997. Véase: http://www.ietf.org/rfc/rfc2141.txt

[RFC 2396]

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

[RFC 2732]

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

Anexo B: Modelo Conceptual XTM (Informativo)

B.0. Introducción

Este anexo presenta el Modelo Conceptual de los Mapas de Tópicos XML. El modelo utiliza una notación sencilla derivada de la notación de modelado de objetos del Lenguaje de Modelado Unificado UML; sólo se describen aquí los aspectos usados en el modelo (y las interpretaciones particulares utilizadas).

Explicación de la Notación usada en el Modelo Conceptual

La notación está compuesta de recuadros o cajas, que representan clases (tipos de cosas), y conexiones entre estas cajas, que representan las relaciones entre las clases, o entre instancias de las clases (casos individuales de los tipos representados por las cajas). Hay cuatro tipos de conexiones diferentes:

Línea con extremo en forma de triángulo hueco: de subtipo a tipo

Esta notación puede observarse de la forma más clara en el diagrama inicial "Jerarquía de Clases". Por ejemplo, los niveles más altos indican que tanto "Recurso" (Resource) y "Concepto no direccionable" son subtipos de "Concepto". Un nivel más bajo, "Cadena de caracteres" se establece como subtipo de "Recurso". Allí dónde un tipo tiene más de un subtipo, son enlazados juntos utilizando una línea horizontal -esto no proporciona ninguna conexión entre los subtipos (por ejemplo. la única relación aseverada aquí entre "Cadena de caracteres" (String) y "Topic" es que ambos son, por separado, subtipos de "Recurso".

Línea con extremo opcionalmente acabado en flecha: asociación con denominación

Esto se puede ver en el diagrama "Un tópico simboliza un concepto": la línea entre "Tópico" (Topic) y "Concepto" (Subject) establece que la relación denominada "simboliza"; se establece entre cero o más Tópicos ("cero o más" es indicado por 0..*) y un Concepto.

Si hay una flecha, esto indica que la relación se produce en un sólo sentido. En este caso, lo que se dice es que dado un Tópico, puede localizarse que Concepto simboliza... pero, dado un Concepto, por ejemplo el personaje llamado "Hamlet", no hay garantía de que se encuentre ningún Tópico que lo simbolice.

Si no hay flecha, esto indica que no hay un sentido definido para la relación. Esto significa que es posible pasar de cualquier extremo al otro.

Una variación adicional en esta notación es que los extremos de las líneas de conexión pueden etiquetarse. Esto puede verse en el diagrama de esquema "Nombre base en el alcance": la etiqueta "+baseNameString" próximo a "Cadena de caracteres" establece que es una "Cadena de caracteres" que sirve como una Cadena de caracteres del nombre base en relación al "Nombre Base".

Finalmente, la conexión en sí misma puede marcarse con un nombre entre ángulos dobles, indicando la naturaleza de la relación (por ejemplo, <<SIMBOLIZA>>).

Línea con extremo en forma de rombo negro: dependencia estricta, denominada comúnmente pertenencia

 Esto puede verse en el diagrama "Nombre Base en el Alcance": la relación de "Nombre Base" a "Tópico" es tal que no tiene sentido llamar a algo nombre base a menos que sea nombre base de un tópico.

Línea con extremo en forma de rombo transparente: conjunto

Esto puede verse en el diagrama "Las Características de Tópico se asignan en los Alcances": la relación de "Tópico" a "Alcance" es que un Alcance es un conjunto de uno de más Tópicos.

En este Anexo, los nombres de clases están en mayúsculas, como: Clase.

  B.1. Jerarquía de Clases

Figura B-1: Jerarquía de Clases (diagrama de clases)

Un Concepto es cualquier cosa acerca de la que se puede hablar o ser concebida por un ser humano. Un Recurso es un Concepto que tiene identidad dentro de los límites de un sistema informático. Cualquier otro Concepto se conoce como Concepto No direccionable. Hay muchos tipos de Conceptos No direccionables. Una Clase es un Concepto No direccionable. Los tipos de Recurso incluyen Cadena de caracteres, Elemento XML, y Atributo XML, así como Mapa de tópicos, Nodo de Mapa de tópicos, Característica de Tópico y muchos otros. Los tipos de Elemento XML incluyen el elemento <topic>, el elemento <association>, y muchos otros. Hay tres tipos de Nodo de Mapa de Tópico: Tópico, Asociación, y Alcance. Hay tres tipos de Característica de Tópico: Nombre Base, Ocurrencia, y Rol.

B.2. Relación Clase-Instancia

 Figura B-2: Relación Clase-Instancia (diagrama de clases)

 Un Concepto puede ser una instancia de cero o más Clases.

B.3. Un Tópico Simboliza un Concepto

Figura B-3: Un Tópico Simboliza un Concepto (diagrama de clases)

Un Tópico es un Recurso que simboliza un Concepto. Es el sistema de representación del Concepto en el Mapa de tópicos. La Simbolización de un Concepto permite asignar Características de Tópico al Tópico que lo simboliza.

B.4. Referenciando el Concepto

Figura B-4: Referenciando el Concepto (diagrama de clases)

Un Tópico puede tener cualquier número de Indicadores de Concepto. Un Indicador de Concepto es un Recurso que indica que Concepto es simbolizado por el Tópico. Si el Concepto es un propiamente un Recurso, puede haber una referencia directa desde el Tópico a ese Recurso además de cualquier referencia que pueda haber a Indicadores de Concepto.

B.5. Las Características de Tópico se asignan en los Alcances

Figura B-5: Las Características de Tópico se asignan en los Alcances (diagrama de clases)

Un Alcance es un conjunto de Tópicos que define la extensión de la validez de la asignación de una Característica de Tópico a un Tópico. Si no se especifica ningún Alcance, se considera que el Alcance es el Alcance libre, y la asignación es siempre válida.

B.6. Nombre base en el Alcance

Figura B-6: Nombre base en el Alcance (diagrama de clases)

Un Nombre base es una Cadena de caracteres usada para denominar un Tópico en un Alcance. Sólo un Tópico puede asignarse a un Nombre base en particular en un Alcance dado. El conjunto de Nombres Base asignados en un Alcance dado constituye así un espacio de nombre, y puede utilizarse para identificar Tópicos sin ambigüedades.

B.7. Ocurrencia

Figura B-7: Ocurrencia (diagrama de clases)

Una Ocurrencia designa un Recurso que está relacionado con un Tópico.

B.8. Asociación entre Tópicos

Figura B-8: Asociación entre Tópicos (diagrama de clases)

Una Asociación relaciona un Tópico con otro. Comprende uno o más Roles, cada uno de los cuales corresponde a un Tópico que especifica un tipo de participación que los Tópicos pueden tener en la Asociación. Cada Rol se asigna a cero o más Tópicos que están involucrados en la Asociación en la forma especificada. Se dice que estos Tópicos son jugadores de ese Rol en la Asociación.

NOTA: En XTM, no se permite que los distintos Roles de una Asociación sean gobernados por Alcances diferentes. La sintaxis XTM expresa los Alcances para todos los Roles una Asociación mediante un único subelemento <scope> del elemento <association>.

B.9. Mapa de Tópicos

Figura B-9: Mapa de Tópicos (diagrama de clases)

Un Mapa de Tópicos comprende cero o más Nodos de Mapa de Tópicos (Tópicos, Alcances, y Asociaciones). Es posible para más de un Tópico en el Mapa de Tópicos cosificar el mismo Concepto. Si ningún Concepto es simbolizado por más de un Tópico en el Mapa de Tópicos, entonces se dice que el Mapa de Tópicos es un Mapa de Tópicos Coherente.

Anexo C: Modelo Conceptual XTM para el mapeo de la Sintaxis de Intercambio (Informativo)

El Modelo Conceptual XTM y su Sintaxis de Intercambio no mapean directamente de uno a otro mediante una correspondencia uno-a-uno entre los constructos sintácticos y los objetos del Modelo Conceptual. Hay varias formas mediante las que los objetos descritos por el Modelo Conceptual pueden relacionarse a constructos de la Sintaxis del Intercambio XTM:

• A veces, un constructo sintáctico ES el objeto descrito por el modelo.
• A veces, un constructo sintáctico REFERENCIA el objeto descrito por el modelo mediante las convenciones de la sintaxis URI.
• A veces, un constructo sintáctico REPRESENTA el objeto descrito por el modelo.
• A veces, el objeto descrito no tiene correspondencia directa en la sintaxis en absoluto, pero ES INDICADO por el contenido legible por humanos de un recurso.

El modo en el que los constructos de la Sintaxis del Intercambio se relacionan con los objetos en el Modelo Conceptual se especifican en las descripciones textuales de los constructos sintácticos en la Sección 3. Documentación de la Sintaxis XTM. Una especificación más formal de estas relaciones está bajo desarrollo y será publicada en un documento posterior de Topicmaps.Org.

Anexo D: XTM 1.0 Definición del Tipo de Documento (Normativa)

Nota: En la versión online de esta DTD, el nombre de cada tipo de elemento de cada declaración de elemento enlaza con documentación en esta especificación. Los nombres de cada tipo de elemento en los modelos de contenido enlazan con sus respectivas declaraciones en la DTD.

<!-- archivo: xtm1.dtd -->
<!-- XML Mapas de tópicos (XTM) DTD, Versión 1.0

Este documento es XTM, una sintaxis de intercambio en XML para la norma
ISO 13250 Topic Maps.

XML Topic Map (XTM)

Copyright 2000-2001 TopicMaps.Org, Todos los derechos reservados.

Se garantiza aquí, a perpetuidad, el permiso para usar, copiar,
modificar y distribuir la DTD XTM y sus materiales adjuntos para
cualquier propósito y sin tasas, a condición de que el anterior copyright
y este párrafo aparezcan en todas las copias.
El titular del copyright no se hace responsable de la idoneidad del DTD 
para ningún uso que de ella se haga. Se distribuye "tal cual" sin garantía
expresa o implícita.

    Editores:  Steve Pepper 		    <pepper@ontopia.net>
 			  Graham Moore	        <gdm@empolis.co.uk>
    Autores:	  Murray Altheim 		<altheim@eng.sun.com>
			      Michel Biezunski		<mb@infoloom.com>
			      Sam Hunting			<shunting@etopicality.com>
			      Steven R. Newcomb		<srn@coolheads.com>
    
    Estatus:	Lanzamiento
    Versión: 	v1.0.1
    Revisión:	$Id: xtm1.dtd,v 1.2 2001/02/08 16:03:12 pepper Exp $
     
    Traducción al español:	Mª Jesús Colmenero Ruiz <mcolmene@bib.uc3m.es>    
    Identificador público:	(esta versión en español no lo posee aún)

          Revisiones:
  #2001-01-21: baseName eliminado de occurrence
  #2001-02-02: variantName hecho opcional en variant
  #2001-02-02: cambiado ID a #IMPLIED en association
  #2001-02-02: cambiado ID a #IMPLIED en resourceData
  #2001-02-02: cambiado PLUS a REP en member
-->

<!-- Use este URI para identificar el espacio de nombre XTM por defecto:
           "(esta DTD en español no posee URI)"
       Usado para identificar  el espacio de nombre XLink:
           "http://www.w3.org/1999/xlink"
-->

<!-- topicMap: elemento documento Mapa de tópicos ........................... -->
<!ELEMENT topicMap ( topic | association | mergeMap )*>
<!ATTLIST topicMap
    id              ID        #IMPLIED
    xmlns           CDATA     #FIXED 'http://(esta DTD en español no posee URI)'
    xmlns:xlink    CDATA     #FIXED 'http://www.w3.org/1999/xlink'
    xml:base       CDATA     #IMPLIED
>

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

<!-- instanceOf: Apunta a un Topic representando una clase................... -->
<!ELEMENT instanceOf  ( topicRef | subjectIndicatorRef ) >
<!ATTLIST instanceOf
     id              ID        #IMPLIED
>

<!-- subjectIdentity: Concepto representado por el Topic .................... -->
<!ELEMENT subjectIdentity ( resourceRef?, ( topicRef | subjectIndicatorRef )* )>
<!ATTLIST subjectIdentity
     id              ID        #IMPLIED
>

<!-- topicRef: Referencia a un elemento Topic................................ -->
<!ELEMENT topicRef  EMPTY >
<!ATTLIST topicRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
>

<!-- subjectIndicatorRef: Referencia a un indicador de Subject............... -->
<!ELEMENT subjectIndicatorRef  EMPTY >
<!ATTLIST subjectIndicatorRef
     id              ID        #IMPLIED
     xlink:type      NMTOKEN   #FIXED 'simple'
     xlink:href      CDATA     #REQUIRED
>

<!-- baseName: Nombre Base o preferente de un Topic ......................... -->
<!ELEMENT baseName ( scope?, baseNameString, variant* ) >
<!ATTLIST baseName
   id              ID        #IMPLIED
>

<!-- baseNameString: Depósito de la cadena de caracteres del nombre base..... -->
  <!ELEMENT baseNameString  ( #PCDATA ) >
  <!ATTLIST baseNameString
     id              ID        #IMPLIED
  >

<!-- variant: Formas alternativas del nombre base............................ -->
<!ELEMENT variant ( parameters, variantName?, variant* ) >
<!ATTLIST variant
    id              ID        #IMPLIED
>

<!-- variantName: Depósito de la variante del nombre......................... -->
<!ELEMENT variantName  ( resourceRef | resourceData ) >
<!ATTLIST variantName
   id              ID        #IMPLIED
  >

<!-- parameters: Contexto de proceso para el elemento Variant ............... -->
<!ELEMENT parameters  ( topicRef | subjectIndicatorRef )+ >
<!ATTLIST parameters
   id              ID        #IMPLIED
>

<!-- occurrence: Recursos considerados como una Occurrence .................. -->
<!ELEMENT occurrence ( instanceOf?, scope?, ( resourceRef | resourceData ) )>
<!ATTLIST occurrence
   id              ID        #IMPLIED
>

<!-- resourceRef: Referencia a un recurso ................................... -->
<!ELEMENT resourceRef  EMPTY >
<!ATTLIST resourceRef
   id              ID        #IMPLIED
   xlink:type      NMTOKEN   #FIXED 'simple'
   xlink:href      CDATA     #REQUIRED
>

<!-- resourceData: Depósito de recurso de datos ............................. -->
<!ELEMENT resourceData  ( #PCDATA )>
<!ATTLIST resourceData
   id              ID        #IMPLIED
>

<!-- association: Relación entre Topics ..................................... -->
<!ELEMENT association ( instanceOf?, scope?, member+ )>
<!ATTLIST association
   id              ID        #IMPLIED
>

<!-- member: Indicación de pertenencia una relación entre Topics ............ -->
<!ELEMENT member (roleSpec?,( topicRef|resourceRef|subjectIndicatorRef )* )>
<!ATTLIST member
   id              ID        #IMPLIED
>

<!-- roleSpec: Apunta a un Topic que funciona describiendo el rol
 realizado en la relación (Association Role)................................. -->
<!ELEMENT roleSpec  ( topicRef | subjectIndicatorRef ) >
<!ATTLIST roleSpec
   id              ID        #IMPLIED
>

<!-- scope: Referencia a un Topic que constituye el contexto de validez ..... -->
<!ELEMENT scope ( topicRef | resourceRef | subjectIndicatorRef )+ >
<!ATTLIST scope
   id              ID        #IMPLIED
>

<!-- mergeMap: Unión con otro Mapa de materias .............................. -->
<!ELEMENT mergeMap  ( topicRef | resourceRef | subjectIndicatorRef )* >
<!ATTLIST mergeMap
   id              ID        #IMPLIED
   xlink:type      NMTOKEN   #FIXED 'simple'
   xlink:href      CDATA     #REQUIRED
>

<!-Fin de la DTD XML Topic Map (XTM) 1.0 -->
      

Anexo E: Indicadores de Concepto Publicados Básicos XTM 1.0 (Normativo)

Nota: En la versión en línea de este mapa de tópicos, el identificador único ("id") de cada elemento tópico o asociación enlaza con documentación en esta especificación.

<?xml version="1.0"?>
<!DOCTYPE topicMap PUBLIC "-//TopicMaps.Org//DTD XML Topic Map (XTM) 1.0//EN"
                        "xtm1.dtd">
<topicMap id="xtm1.0-psi-básicos"
    xmlns="http://www.topicmaps.org/xtm/1.0/"
    xml:base="http://www.topicmaps.org/xtm/1.0/">
<!--
     Indicadores de Concepto Publicados Básicos XTM 1.0  (PSIs)

     XML Topic Map (XTM)
       Copyright 2000-2001 TopicMaps.Org, Todos los derechos reservados.

     Se garantiza aquí, a perpetuidad, el permiso para usar este documento
     para cualquier propósito y sin tasas, a condición de que el anterior 
     copyright y este párrafo aparezcan en todas las copias. El titular del
     copyright no se hace responsable de su idoneidad para ningún uso que de
     él se haga. Se distribuye "tal cual" sin garantía expresa o implícita.


    Editores:     Steve Pepper           <pepper@ontopia.net>
                       Graham Moore       <gdm@empolis.co.uk>
    Estatus:       Final
    Versión:      v1.0
    Revisión:   $Id: core.xtm,v 1.3 2001/02/21 21:27:27 pepper Exp $
    Traducción al español:  Mª Jesús Colmenero Ruiz     <mcolmene@bib.uc3m.es> 
    Identificador público:      (esta versión en español no lo posee aún)
     "-//TopicMaps.Org//DOCUMENT XTM 1.0 Core Published Concepto Indicators//EN"

        Revisiones:
#2000-12-03: añadidos comentarios de XTM 1.0 Básico
#2001-02-01: revisión importante para adaptarlo a las decisiones de París
#2001-02-01: intercambiadas las descripciones en ocurrencias e indicadores 
                     de concepto 
-->
<!-- Indicadores de Concepto Publicados XTM 

     Los elementos topic en este documento están diseñados para servir como
     indicadores de concepto publicados para tópicos declarados en otros mapas
     de tópicos cuyos conceptos son los mismos que los conceptos de estos
     elementos topic.

       En el mapa de tópicos que referencia, las direcciones usadas para
       referirse a estos elementos topic deben utilizar los identificadores 
       únicos (p.e. los valores "URI" indicados en las ocurrencias) de estos
       elementos, porque sus los identificadores únicos son permanentes; sus 
       posiciones relativas en el documento no son necesariamente permanentes.
       El direccionamiento puede hacerse indirectamente vía un elemento topic.

       TopicMaps.Org se reserva el derecho de incrementar la utilidad de
       estos indicadores de concepto publicados, y de proporcionar
       indicadores de concepto publicados adicionales, aunque sólo de forma que
       no impacte negativamente en el valor o utilidad de cualesquiera
       documentos mapa de tópicos conformes existentes.

       Los conceptos de estos indicadores de concepto publicados se describen
       en la Especificación XTM 1.0 como "obligatorios", esto es, las 
       aplicaciones conformes  deben tener la capacidad de soportar el uso
       de estos conceptos tal como se describe en la  Especificación XTM 1.0.

       Los indicadores de concepto referenciados por estos elementos topic son
       las partes de la Especificación XTM 1.0 que proporcionan sus
       descripciones normativas. Otros mapas de tópicos deben utilizar
       normalmente estos elementos topic como los puntos de identidad de estos
       conceptos, más que los indicadores de concepto a los que ellos mismos
       referencian. Estos elementos topic pueden editarse, en alguna fecha
       futura, de forma que proporcionen indicadores de concepto adicionales
       que se referirán a cualquier porción de futuras versiones de la
       Especificación XTM que describa el mismo concepto.

-->

<!-- inicio: conceptos básicos XTM -->

<topic id="tópico">
  <subjectIdentity>
    <subjectIndicatorRef xlink:href="index.html#psi-topico"/>
    <subjectIndicatorRef xlink:href="#psi-descripcion-tópico"/>
  </subjectIdentity>
  <baseName>
  	<scope>
		<topicRef xlink:href="language.xtm#es"/>
	</scope>
    <baseNameString>tópico</baseNameString>
  </baseName>
  <occurrence>
    <resourceData id="psi-descripcion-tópico">
      Tópico: El concepto central de tópico; la clase genérica a la cual
      todos los tópicos pertenecen a menos que se especifique otra cosa.
      URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#topic
    </resourceData>
  </occurrence>
</topic>

<topic id="asociación">
  <subjectIdentity>
    <subjectIndicatorRef xlink:href="index.html#psi-association"/>
    <subjectIndicatorRef xlink:href="#psi-association-description"/>
  </subjectIdentity>
    <baseName><scope><topicRef
        xlink:href="language.xtm#es"/></scope>
        <baseNameString>asociación</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-association-description">
          Asociación: El concepto central de asociación; la clase genérica
          a la cual todas las asociaciones pertenecen a menos que se especifique
          otra cosa.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#association
        </resourceData>
      </occurrence>
    </topic>

    <topic id="ocurrencia">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-occurrence"/>
        <subjectIndicatorRef xlink:href="#psi-occurrence-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef
            xlink:href="language.xtm#es"/></scope>
        <baseNameString>ocurrencia</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-occurrence-description">
          Ocurrencia: El concepto central de ocurrencia; la clase genérica a la
          cual todas las ocurrencias pertenecen a menos que se especifique
          otra cosa.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#occurrence
        </resourceData>
      </occurrence>
    </topic>

    <!-- fin: conceptos básicos XTM -->

    <!-- inicio: la relación clase-instancia -->
<topic id="relación-clase-instancia">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-class-instance"/>
        <subjectIndicatorRef xlink:href="#psi-class-instance-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#es"/></scope>
        <baseNameString> relación clase-instancia </baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-class-instance-description">
           Relación clase-instancia: El concepto central de clase-instancia;
           la clase de asociación que representa relaciones clase-instancia
           entre tópicos, y que es semánticamente equivalente al uso
           de los subelementos <instanceOf>.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#class-instance
        </resourceData>
      </occurrence>
    </topic>

    <topic id="clase">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-class"/>
        <subjectIndicatorRef xlink:href="#psi-class-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#es"/></scope>
        <baseNameString>clase</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-class-description">
         Clase: El concepto central de clase; el papel de clase tal como es
         jugado por uno de los miembros de una asociación clase-instancia.
         URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#class
        </resourceData>
      </occurrence>
    </topic>

    <topic id="instancia">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-instance"/>
        <subjectIndicatorRef xlink:href="#psi-instance-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#es"/></scope>
        <baseNameString>instancia</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-instance-description">
          Instancia: El concepto central de instancia; el papel de instancia tal
          como es jugado por uno de los miembros de una asociación
          clase-instancia.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#instance
        </resourceData>
      </occurrence>
    </topic>

    <!-- fin: la relación clase-instancia -->

    <!-- inicio: la relación superclase-subclase -->

    <topic id="relación superclase-subclase">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-superclass-subclass"/>
        <subjectIndicatorRef xlink:href="#psi-superclass-subclass-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#es"/></scope>
        <baseNameString>relación superclase-subclase</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-superclass-subclass-description">
          Relación superclase-subclase: El concepto central superclase-subclase;
          la clase de asociación que representa relaciones superclase-subclase
          entre tópicos.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#superclass-subclass
        </resourceData>
      </occurrence>
    </topic>

    <topic id="superclase">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-superclass"/>
        <subjectIndicatorRef xlink:href="#psi-superclass-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#es"/></scope>
        <baseNameString>superclase</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-superclass-description">
          Superclase: El concepto central de superclase; el papel de superclase
          tal como es jugado por uno de los miembros de una asociación
          superclase-subclase.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#superclass
        </resourceData>
      </occurrence>
    </topic>

    <topic id="subclase">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-subclass"/>
        <subjectIndicatorRef xlink:href="#psi-subclass-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#es"/></scope>
        <baseNameString>subclase</baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-subclass-description">
          Subclase: El concepto central de subclase; el papel de subclase
          tal como es jugado por uno de los miembros de una asociación
          superclase-subclase.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#subclass
        </resourceData>
      </occurrence>
    </topic>

    <!-- fin: la relación superclase-subclase -->

    <!-- inicio: conceptos de los parámetros de la variante de nombre -->

    <topic id="Idoneidad-para-la-ordenación">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-sort"/>
        <subjectIndicatorRef xlink:href="#psi-sort-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#es"/></scope>
        <baseNameString> Idoneidad para la ordenación </baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-sort-description">
          Idoneidad para la ordenación: Idoneidad de un nombre de tópico para
          ser usado como una clave corta; de uso en los parámetros de las
          variantes de nombre.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#sort
        </resourceData>
      </occurrence>
    </topic>

    <topic id="Idoneidad-para-la-visualización">
      <subjectIdentity>
        <subjectIndicatorRef xlink:href="index.html#psi-display"/>
        <subjectIndicatorRef xlink:href="#psi-display-description"/>
      </subjectIdentity>
      <baseName><scope><topicRef xlink:href="language.xtm#es"/></scope>
        <baseNameString> Idoneidad para la visualización </baseNameString>
      </baseName>
      <occurrence>
        <resourceData id="psi-display-description">
          Idoneidad para la visualización: Idoneidad de un nombre de tópico para
          su visualización; de uso en los parámetros de las variantes de nombre.
          URI:  http://www.topicmaps.org/xtm/1.0/core.xtm#display
        </resourceData>
      </occurrence>
    </topic>

    <!-- fin: conceptos de los parámetros de la variante de nombre -->

  <!-fin de Indicadores de Concepto Publicados XTM 1.0 (PSIs) -->

  </topicMap>

Además del mapa de tópicos Indicadores de Concepto Publicados XTM 1.0 mostrado arriba, se proporcionan mapas de tópicos XTM para idiomas y países (p. ej. para ser usados en la internacionalización de mapas de tópicos):

• Indicadores de Concepto Publicados XTM 1.0 (básico.xtm)
• Tópicos de Idioma XTM (language.xtm)
• Tópicos de Países XTM (country.xtm)

Anexo F: Requisitos de Procesamiento XTM (Informativo)

F.1. Introducción

Este anexo describe los requisitos mínimos de un procesador XTM conforme. Se requiere, como mínimo, que un procesador XTM sea capaz de procesar uno o más documentos mapa de tópicos en un modelo interno que represente la información del mapa de tópicos contenida en esos documentos de tal forma que sea accesible a los clientes del procesador un mapa de tópicos coherente.

Los requisitos del procesamiento de XTM se indican en términos de:

• Principios de igualdad
• Principios de equivalencia
• Operaciones con variantes
• Operaciones de unión
• Supresión de duplicados

F.2. Principios de Igualdad

Las siguientes declaraciones de igualdad definen las reglas por las que un procesador XTM conforme debe determinar la igualdad de partes del mapa de tópicos.

F.2.1. Principio de igualdad de las cadenas de caracteres

Un procesador XTM conforme debe poder comparar dos cadenas de caracteres para determinar su coincidencia. Antes de realizar cualquier comparación, el procesador XTM debe trasformar todas las cadenas de caracteres a formato Unicode/ISO 10646. Una vez hecha la transformación, dos cadenas de caracteres se consideran iguales si están codificadas como secuencias idénticas de valores escalares. Una aplicación que procese XTM conforme puede aplicar algoritmos adicionales para determinar la igualdad de las cadenas de caracteres.

F.2.2. Principio de igualdad de URI's

Un procesador XTM conforme debe considerar que dos URIs son iguales cuando la igualdad se establece mediante la aplicación de las reglas definidas por el esquema apropiado de URI.

La sección 6 de RFC 2396 proporciona la definición general de como se determina la igualdad de dos URIs. A continuación se indica un conjunto de referencias a esquemas de URI que debe soportar un procesador XTM conforme:

• http (RFC 1738 sección 3.3)
• ftp (RFC 1738 sección 3.2)
• https (RFC 1738 sección 3.3)
• file (RFC 1738 sección 3.10)
• urn (RFC 2141),
• • Un procesador XTM conforme debe decidir la igualdad de URNs basándose en las reglas de equivalencia definidas en la sección 6 de RFC 2396.
  • Un procesador XTM conforme puede decidir la igualdad de URNs basándose en las definiciones de la documentación de esquemas URNs particulares.

F.2.3. Principio de igualdad de los alcances

En un mapa de tópicos coherente un procesador XTM conforme debe considerar que dos alcances son iguales si contienen el mismo conjunto de tópicos.

F.2.4. Principio de igualdad de las asociaciones.

Un procesador XTM conforme debe considerar que dos asociaciones son iguales si se cumple lo siguiente:

1. Las asociaciones constan del mismo conjunto de roles.
2. El conjunto de los tópicos que juegan cada rol en las asociaciones es igual.
3. Las asociaciones son instancias de la misma clase.
4. Los alcances de las asociaciones son iguales tal y como se define en el principio de la igualdad de los alcances.

F.2.5. Principio de igualdad de los nombres de tópicos

Dos nombres base se consideran iguales si es verdad lo siguiente:

1. Los valores de la cadena de caracteres de los nombres base son iguales tal como se define en el principio de la igualdad de cadena de caracteres.
2. Los alcances de los nombres base son igual tal como se define en el principio de igualdad de los alcances. Las variantes de nombre se ignoran al decidir si dos nombres son iguales.

F.2.6. Principio de igualdad de ocurrencia de tópico

Dos ocurrencias de tópico se consideran iguales si es verdad lo siguiente:

1. En el caso de los elementos <resourceRef>, los URIs utilizados para direccionar las ocurrencias son equivalentes tal como está definido por el principio de la igualdad de URIs; o en el caso de los elementos, los valores de los recursos de datos que son las ocurrencias son iguales. (Antes de que se produzca cualquier comparación de, un procesador de XTM debe transformar todas las cadenas de caracteres a Unicode/ISO 10646. Hecho esto, dos valores de recurso de datos se consideran iguales si están codificados como secuencias idénticas de valores escalares).
2. Las ocurrencias pertenecen a la misma clase.
3. Los alcances de las ocurrencias son iguales tal como se define en el principio de igualdad de los alcances.

F.3. Principios de Equivalencia

Los principios de equivalencia indican las diferentes formas en las que los mismos nodos de mapa de tópicos pueden representarse sintácticamente. Un procesador XTM conforme debe reconocer todas las representaciones sintácticas equivalentes de constructos mapa de tópicos, tal como se enumeran en esta sección, y procesarlos de tal manera que en el mapa de tópicos procesado sea indetectable que representaciones sintácticas se usaron.

F.3.1. Equivalencia de <subjectIndicatorRef> y <topicRef>

Un elemento <subjectIndicatorRef> que referencia un tópico A puede ser expresado de manera equivalente por un elemento <topicRef> que también referencia el tópico A.

Un elemento <subjectIndicatorRef> que referencia un recurso distinto a un tópico puede ser expresado de manera equivalente por un elemento <topicRef> que referencia un tópico que considera el recurso como un indicador de concepto.

F.3.2. Equivalencia de <instanceOf> y <association>

Un elemento <instanceOf> expresa una relación entre el <topic>, T, referenciado desde el elemento hijo del elemento <instanceOf> el elemento y el <topic>, <association> u <occurrence> que sea el elemento padre del elemento <instanceOf>.

Esta relación puede ser expresada de una manera equivalente mediante una <association> que es una instancia del concepto publicado "clase-instancia" y que tiene dos roles en el alcance libre -el rol "clase" y el rol "instancia". El jugador del rol "clase" es el tópico T. Si el elemento padre de <instanceOf> es un elemento <topic> entonces el jugador del rol "instancia" es el tópico representado por ese elemento <topic>. Si el elemento padre de <instanceOf> no es un elemento <topic>, entonces el jugador del rol "instancia" es un tópico que simboliza la asociación u ocurrencia representadas por ese elemento padre.

Si un elemento <association> se usa para expresar una relación "clase-instancia" es un Error XTM del que debe informarse si cualquiera de las siguientes cosas es verdad:

1. El rol "clase" es jugado por un tópico con un concepto direccionable.
2. Ninguno de los dos roles "clase" o "instancia" son roles de la asociación.
3. Forman parte de la asociación roles distintos a "clase" e "instancia".

F.3.3. Equivalencia de múltiples <member>s del mismo rol

Una asociación que contiene múltiples miembros (elementos <member>), M1 y M2, del mismo rol R puede ser puede ser definida de manera equivalente por una asociación que contiene un solo miembro M3 del rol R cuyo conjunto de jugadores es la unión de los conjuntos de jugadores del rol R de los miembros M1 y M2.

F.4. Operaciones con las variantes

F.4.1. Procesamiento de las variantes del alcance

El contexto de proceso de una variante de nombre definido por un elemento <variant> se define como la unión de los parámetros del elemento <variant> y todos sus elementos ancestros <variant>. Así una variante de nombre con un conjunto de parámetros es equivalente a tener el mismo conjunto de parámetros en un variante padre y no tener parámetros adicionales.

F.5. Operaciones de Unión

F.5.1. Operación de unión de tópicos

Condición previa:

1. Dos tópicos, A y B serán unidos.

Condición posterior:

1. Existe un único tópico M
2. El conjunto de características de nombre de M es igual a la unión del conjunto de características de nombre de A y B.
3. El conjunto de indicadores de concepto de M es igual a la unión del conjunto de indicadores de concepto de A y B
4. El concepto direccionable de M es igual al concepto direccionable de A o B.
5. M reemplaza A y B como jugador de cualquier rol jugado en las asociaciones en el mapa de tópicos.
6. El conjunto de ocurrencias de M es igual a la unión de las ocurrencias de A y B
7. A y B no existen.

Condiciones de Error:

Será un Error XTM que debe informarse si:

1. Los tópicos A y B tienen diferentes conceptos direccionables

Ejemplo:

Antes:

<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>El Príncipe de Dinamarca </baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet_again.html"/>
      </occurrence>
    </topic>
     <association>
      <member>
        <roleSpec> <topicRef xlink:href="#t-obra"/> </roleSpec>
        <topicRef xlink:href="#t-hamlet"/>
      </member>
      <member>
        <roleSpec> <topicRef xlink:href="#t-c"/> </roleSpec>
        <topicRef xlink:href="#t34"/>
      </member>
    </association>
     <association>
      <member>
        <roleSpec> <topicRef xlink:href="#t-obra"/> </roleSpec>
         <topicRef xlink:href="#t-hamlet"/>
      </member>
      <member>
        <roleSpec> <topicRef xlink:href="#t-v"/> </roleSpec>
        <topicRef xlink:href="#t35"/>
      </member>
    </association>
   </topicMap>

Después:

  <topicMap>
   <!-- Nótese que los tópicos se han unido y como resultado de ello
    se aplica la regla de redundacia de duplicados de asociación. Esto elimina 
    la asociación que ahora está duplicada.                    -->
    
    <topic id="t36">
     <baseName>
        <baseNameString>Hamlet</baseNameString>
      </baseName>
       <baseName>
        <baseNameString>The Prince Of Denmark</baseNameString>
      </baseName>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet.html"/>
      </occurrence>
      <occurrence>
        <resourceRef xlink:href="http://www.topicmaps.org/examples/hamlet_again.html" />
      </occurrence>
    </topic>

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

F.5.2. Operación de unión basada en el Concepto

Condición previa:

Dos tópicos A y B existen en el mapa de tópicos M en tanto que:

1. los URIs de los conceptos direccionables de A y B son iguales según el principio de la igualdad de URIs, o
2. el tópico B es un indicador de concepto del tópico A, o
3. Existen dos URIs U1 y U2, donde U1 es un indicador de concepto del tópico A y U2 es un indicador de concepto del tópico B y U1 es igual a U2 según el principio de la igualdad de URIs, o
4. Existen dos URIs U1 y U2, donde U1 es un indicador de concepto del tópico A y U2 es un indicador sujeto del tópico B y la aplicación de proceso de XTM ha determinado vía un proceso específico de la aplicación que el indicador de concepto referenciado por U1 señala el mismo concepto que el referenciado por U2.

Condición posterior:

1. Los tópicos A y B son unidos con las condiciones previas y posteriores tal como es especificado por la operación de unión de tópicos.

Ejemplo 1. Las URIs de los conceptos direccionables de A y B son iguales:

Antes:

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

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

Después:

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

Ejemplo 2. Los dos tópicos tienen al menos un indicador de concepto URI en común:

Antes:

   <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>La tragedia de Hamlet, Príncipe de Dinamarca </baseNameString>
    </baseName>
  </topic>
</topicMap>

Después:

<topicMap>
  <topic id="t3">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.shakespeare.org/plays/hamlet.html" />
      <subjectIndicatorRef xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt" />
    </subjectIdentity>
    <baseName>
      <baseNameString>Hamlet </baseNameString>
    </baseName>
    <baseName>
      <baseNameString> La tragedia de Hamlet, Príncipe de Dinamarca </baseNameString>
    </baseName>
  </topic>
</topicMap>

F.5.3 Unión basada en la restricción de denominación de tópico

Condición previa:

Dos tópicos A y B existen en el mapa de tópicos M en modo tal que:

1. El tópico A tiene una cadena de caracteres del nombre base B1 en un alcance S1 y,
2. El tópico B tiene una cadena de caracteres del nombre base B2 en el alcance S2 y,
3. El alcance S1 es igual al alcance S2 según el principio de la igualdad del alcance y,
4. La cadena de caracteres del nombre base B1 es igual a la cadena de caracteres del nombre base B2 según el principio de la igualdad de las cadenas de caracteres.

Condición posterior:

1. T1 y T2 son unidos según la operación de unión de tópicos.

Nota: Los alcances S1 y S2 pueden ser el alcance libre.

Ejemplo 1. Unión basada en la restricción de denominación de tópicos en el alcance libre.

Antes:

<topic id="t1">
 <baseName>
  <baseNameString>Hamlet, Príncipe de Dinamarca </baseNameString>
 </baseName>
</topic>

<topic id="t2">
 <baseName>
  <baseNameString>Hamlet, Príncipe de Dinamarca </baseNameString>
 </baseName>
</topic>

Después:

<topic id="t3">
 <baseName>
  <baseNameString>Hamlet, Príncipe de Dinamarca </baseNameString>
 </baseName>
</topic>

Ejemplo 2. Unión basada en la restricción de denominación de tópicos con alcance:

Antes:

<topicMap>
 <topic id="t1">
  <baseName>
   <scope>
    <topicRef xlink:href="#tragedia-shakespeariana"/>
   </scope>
 	  <baseNameString>Hamlet, Príncipe de Dinamarca</baseNameString>
  </baseName>
 </topic>

 <topic id="t2">
  <baseName>
   <scope>
    <topicRef xlink:href="# tragedia-shakespeariana"/>
   </scope>
    <baseNameString>Hamlet,Príncipe de Dinamarca</baseNameString>
  </baseName>
 </topic>
</topicMap>

Después:

<topicMap>
 <topic id="t3">
  <baseName>
   <scope>
    <topicRef xlink:href="#tragedia-shakespeariana"/>
   </scope>
    <baseNameString>Hamlet,Príncipe de Dinamarca</baseNameString>
  </baseName>
 </topic>
</topicMap>

F.5.4. Unión explícita de mapas de tópicos

Condición previa:

1. Un elemento mergeMap es procesado en el mapa de tópicos M que referencia al documento mapa de tópicos D.
2. El elemento mergeMap contiene referencias a un conjunto de conceptos S a través de sus elementos hijos.

Condición posterior:

1. Cada tópico y asociación en D es añadido al mapa del tópicos; el alcance de cada nombre base, ocurrencia y rol en la asociación con origen en D es expresado como la unión del conjunto de conceptos en su alcance original y el conjunto S.

Nota: Cualquier directiva de unión en D es procesada posteriormente según esta regla. Los conjuntos de conceptos S van siendo acumulados por debajo de la cadena.

F.5.5. Unión implícita de mapas de tópicos

Condición previa:

1. Se procesa un elemento <topicRef>.
2. El <topicRef> procesado referencia un tópico en un mapa de tópicos, M, que no se ha procesado aún.
3. La aplicación decide resolver el <topicRef> al tópico referenciado

Condición posterior:

1. Cada tópico y asociación en M son añadidos es añadido al mapa de tópicos, pudiendo producirse uniones y supresiones de duplicados adicionales.

Nota: Cualquier directiva de unión en M es procesada según la regla de unión explícita de mapas de tópicos.

F.6. Supresión de duplicados

F.6.1 Supresión de duplicados de Indicadores de Concepto

Condición previa:

1. Hay un tópico A en el mapa de tópicos M con dos referencias URI a indicadores de concepto, U1 y U2.
2. U1 es igual a U2 según el principio de equivalencia de URI´s.

Condición posterior:

La referencia al indicador de concepto especificada por U2 es eliminada de A

Ejemplo:

Antes:

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

Después:

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

F.6.2. Supresión de duplicados de nombres de tópico

Condición previa:

1. Hay un tópico A en el mapa de tópicos M con un nombre base B1 que contiene una cadena de caracteres del nombre base N1 en el alcance S1 y un nombre base B2 que contiene una cadena de caracteres del nombre base N2 en el alcance S2.
2. N1 es igual a N2 tal como es definido por el principio de igualdad de las cadenas de caracteres.
3. S1 es igual a S2 tal como es definido por el principio de igualdad del alcance.

Condición posterior:

1. Se crea un nombre base B3 que contiene una cadena de caracteres del nombre base N1 en un alcance igual a S1.
2. Todas las variantes de B1 son añadidos a B3.
3. Todas las variantes de B2 son añadidos a B3.
4. B3 se añade al conjunto de nombres de A.
5. B1 y B2 desaparecen.

F.6.3. Supresión de duplicados de asociación.

Condición previa:

1. El mapa de tópicos contiene dos asociaciones A1 y A2
2. A1 es igual a A2 tal como define el principio de igualdad de asociación.

Condición posterior:

1. A2 es eliminado del mapa de tópicos

Ejemplo:

Antes:

<topicMap>
  <!-- definición de los tópicos necesarios
      ...
      -->
  <association id="a34">
    <member>
      <roleSpec> <topicRef xlink:href="#hermano" /> </roleSpec>
      <topicRef xlink:href="#gdm" />
      <topicRef xlink:href="#ctb" />
    </member>
  </association>
  
  <association id="a35">
   <member>
     <roleSpec> <topicRef xlink:href="#hermano" /> </roleSpec>
     <topicRef xlink:href="#gdm" />
     <topicRef xlink:href="#ctb" />
   </member>
  </association>
</topicMap>

Después:

<topicMap>
  <!-- definición de los tópicos necesarios
      ...
      -->
  <association id="a34">
    <member>
      <roleSpec> <topicRef xlink:href="#hermano" /> </roleSpec>
      <topicRef xlink:href="#gdm" />
      <topicRef xlink:href="#ctb" />
    </member>
  </association>
</topicMap>

F.6.4. Supresión de duplicados de participantes en roles

Condición previa:

1. Una asociación A tiene los miembros M1 y M2
2. M1 y M2 referencian el mismo tópico RT como el tópico que define el rol
3. M1 y M2 referencian el mismo tópico RPT como el tópico que realiza o juega el rol

Condición posterior:

1. M2 es eliminado de la asociación A.

Ejemplo:

Antes:

<topicMap>
  <!-- definición de los tópicos necesarios
      ...
      -->
  <association id="a34">
    <member>
      <roleSpec> <topicRef xlink:href="#hermano" /> </roleSpec>
      <topicRef xlink:href="#gdm" />
    </member>
    <member>
      <roleSpec> <topicRef xlink:href="hermano"/> </roleSpec>
      <topicRef xlink:href="#gdm" />
    </member>
    <member>
      <roleSpec> <topicRef xlink:href="#hermano" /> </roleSpec>
      <topicRef xlink:href="#ctb" />
    </member>
  </association>
</topicMap>

Después:

<topicMap>
  <!-- definición de los tópicos necesarios
      ...
      -->
  <association id="a34">
    <member>
      <roleSpec> <topicRef xlink:href="#hermano" /> </roleSpec>
      <topicRef xlink:href="#gdm" />
    </member>
    <member>
      <roleSpec> <topicRef xlink:href="#hermano" /> </roleSpec>
      <topicRef xlink:href="#ctb" />
    </member>
  </association>
</topicMap>

Anexo G: Transformación de Documentos ISO 13250 a XTM (Informativo)

Este anexo proporciona un enlace a información que describe la transformación de documentos mapa de tópicos conformes a la norma ISO 13250 a sintaxis XTM 1.0.

1. Transformación de Documentos ISO 13250 a XTM 1.0

Anexo H: Agradecimientos (Informativo)

El desarrollo de XML Topic Maps (XTM) 1.0 fue un esfuerzo de equipo, dirigido por el Grupo de Autores de Topicmaps.Org. Los editores quisieran agradecer a las personas siguientes en particular por sus importantes contribuciones al proceso editorial:

• Michel Biezunski & Steven R. Newcomb (copresidentes,Subgrupo Sintaxis de Intercambio) Daniel Rivers-Moore (presidente, Subgrupo Modelo Conceptual) Kal Ahmed (presidente, Subgrupo Requisitos de Procesamiento) Murray Altheim & Sam Hunting (editores asociados)

Los Miembros Participantes del Grupo de Autores de Topicmaps.Org activos en el momento de la publicación son:

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

Agradecen también a los Invitados y otras personas que han realizado valiosas contribuciones al proceso:

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

Muchas gracias a otros que han proporcionado comentarios y retroalimentación, así como a aquéllas organizaciones que han sostenido el desarrollo de XTM comprometiéndose con sus valiosos recursos.

Finalmente, querríamos agradecer a Shakespeare & Company permitirnos usar la URL de su sitio web en nuestros ejemplos.

* miembro fundador de TopicMaps.Org.