El profesional de la información


Octubre 1999

Instrumentos terminologicos en el www: xml

Por Antonio de la Rosa

Resumen: El propósito de este artículo es revisar la presencia de instrumentos terminológicos en el www, sus problemas y las posibles soluciones, como la falta de un formato para intercambiar información estructurada o semiestructurada. Los tesauros online en los que se centra el trabajo se entienden, por un lado, como instrumentos clasificatorios de microdisciplinas presentes en el www y, por otro, como fuentes de términos normalizados para la construcción de queries. En ambos casos se propone el estándar xml más algunas de sus especificaciones (XLink, xml-ql, SOX, etc.) para diseñar, mantener, gestionar e intercambiar estos lenguajes documentales.

Palabras clave: Instrumentos terminológicos, Xml, Sgml, TEI (text encoding initiative), Html, Objetos digitales, Jerarquía, XLink, Proyecto Ceres, Proyecto VHG (virtual hyperglossary), Bases de datos terminológicas.

Title: Tools for terminology on the www: xml

Abstract: This article reviews the occurrence of terminology tools on the www, their problems (mainly the lack of a format for the exchange of structured or semistructured information) and possible solutions. The online thesauri in which this article is based are understood on one hand as classification tools of current microdisciplines on the www and, on the other, as standardized resources of terminology for query construction. In both cases xml and some of its specifications (XLink, xml-ql, SOX and so forth) are proposed for the design, maintenance, management and exchange of these thesauri.

Keywords: Terminology tools, Xml, Sgml, TEI (text encoding initiative), Html, Digital objects, Hierarchy, XLink, Ceres project, VHG (virtual hyperglossary) project, Terminology databases.

Rosa, Antonio de la. “Instrumentos terminológicos en el www: xml”. En: El profesional de la información, 1999, octubre, v. 8, n. 10, pp. 14-36.

Antonio de la RosaLas organizaciones reconocen cada vez más la importancia de intercambiar electrónicamente lo que llaman conocimiento corporativo. Éste es un proceso realmente difícil en el que participan muchos tipos de información, aunque el software basado en xml (extensible markup language) permite cierto grado de formalización del conocimiento a un precio razonable puesto que, para las empresas, la rentabilidad es el mejor argumento.

Cuando se habla de gestión del conocimiento es una forma de aludir al proceso humano de la información. Su núcleo es el lenguaje entendido como medio de comunicación, de establecimiento de procesos y también como un método para realizar tareas documentales como la catalogación, clasificación, indización o recuperación de datos.

Las formalizaciones del lenguaje son siempre difíciles. Sin embargo, en muchos campos existe la posibilidad de recoger el conocimiento en ontologías como pueden ser glosarios, tesauros o diccionarios. Esta opción tiene más valor desde que es posible interconectar el conocimiento mediante hiperenlaces.

 

Es el caso de algunos tesauros offline de entorno Windows pero, sobre todo, de los instrumentos diseñados con las especificaciones sgml (standard generalized markup language, definido por la norma ISO 8879), TEI (text encoding initiative), Hytime (hypermedia time-based structuring language)1 y html. Si los recursos informativos interconectados tienen la calidad suficiente, el valor de esos documentos crece manifiestamente. Con los hiperenlaces basados en xml (XLink, extensible linking language) las posibilidades se multiplican.

Colecciones terminológicas en el www

Aunque hay muchos ejemplos en internet realizados en html, no existe un mínimo de normalización entre ellos y es difícil consultar eficientemente esos recursos o utilizar sus términos para formular consultas en buscadores. Esto les resta buena parte de su utilidad. Además, mantener esta categoría de instrumentos en html es sumamente difícil.

En la Red existen recursos terminológicos de gran calidad como el Mesh (medical subject headings) para buscar bibliografía en la base de datos Medline mediante formularios html. Sin embargo, al no haber ningún formato estándar para estas herramientas, cada una desarrolla el suyo propio. Por esta razón es imposible crear aplicaciones que procesen, por ejemplo, los términos de varios tesauros relacionados, a no ser que se basen en el análisis de hiperenlaces html como el WebAnalyzer de Microsoft. El mayor problema es que al intercambiar los tesauros a través del web se pierde toda su estructura y, por lo tanto, la mayor parte de su valor.

Así que en el www persisten algunas de las mismas cuestiones que ya se señalaron en el artículo “Tesauros, tesauros automáticos, tesauros automáticos online”2:

  • La relativa incapacidad para dotar de una arquitectura estable a los términos de un tesauro online, entendida ésta como un contexto.
  • La falta de normalización en lo referente a un formato de información estructurada o semiestructurada.
  • La carencia en cuanto a regularización (e incluso su exceso a veces) en la recuperación y gestión de estructuras de identificación más simples como los metadatos.

Tesauros en html

Adult literacy tesaurus
http://www.pmei.com
American National Institute for Literacy. Relaciones NT, BT, RT implementadas mediante hipertexto. Cada descriptor asignado a una categoría. Usa el software para tesauros Lexico.

CDU (Clasificación decimal universal)
http://www.chem.ualberta.ca/~plambeck/udc

Versión en inglés incompleta disponible en el web de la University of Alberta.

Chemical abstracts general subject vocabulary helper
http://www.cas.org/vocabulary
/index.html

Versión número 14. Presentaciones alfabética y jerárquica. Referencias cruzadas entre los índices de las diferentes versiones. Las páginas de los descriptores incluyen relaciones (hiperenlaces): jerárquicas, UF, USE, términos relacionados y términos antiguos.

Clasificación CDU de bases de datos wais
http://www.ub2.lu.se/
autoclass.html

Jerárquica. Tras la selección de clase, el resultado final es una lista ordenada de bases de datos wais indexadas bajo el epígrafe de la materia correspondiente.

Clasificación decimal Dewey
http://www.oclc.org/oclc/fp/
about/ddc21sm1.htm
Mantenida por la Oclc. Versión bastante reducida de la edición número 21 de la clasificación Dewey.

Clasificación decimal Dewey. Interfaz Wwlib
http://www.scit.wlv.ac.uk/
wwlib/browse.htm l

Comenzando con las diez categorías principales se puede navegar hacia abajo. No es posible hacer consultas. Las clases están enlazadas con los fondos de la biblioteca de la University of Wolverhampton.

Eric thesaurus
http://ericae.net/scripts/ewiz/
amain2.asp

Tesauro del Educational Resources Information Center en EUA. Contiene todas las relaciones estándar. La interfaz inicial es sólo de consulta.

Eurodicautom
http://www2.echo.lu/edic

El sitio web oficial para acceder a la base de dats terminológica de la UE. Términos, definiciones, etc. en la mayoría de los idiomas de la UE. Una gateway se puede hallar en:
http://www.leeming.wa.edu.
au/WWWTour/local/foreign/
euro1.htm

Gnomon thesauri
http://www.gnomon .
ku-eichstaett.de/Gnomon/
Thesaurusanzeige.html

Conjunto facetado de tesauros alemanes. Es utilizado en la base de datos Gnomon de estudios clásicos. Se puede acceder a través de la presentación facetada o hacer directamente una consulta por término. Las respuestas están enlazadas con toda la bibliografía relevante en la base de datos. Cada documento incluye términos de indización pertenecientes al tesauro y también hipertextualizados. Es posible bajarse la versión completa del tesauro (facetada o alfabética).

Iconclass
http://iconclass.let.ruu.nl/
home.html

Sistema de clasificación iconográfica desarrollado en Holanda para obras de arte. Contiene 24.000 entradas de objetos, personas, sucesos, situaciones e ideas abstractas, además de 13.000 palabras clave para describir documentación visual. Utiliza una notación alfanumérica. Dispone de muchos tipos de capacidad de consulta. Una de las interfaces está basado en Java.

Library of Congress classification (LCC)
http://lcweb.loc.gov/catdir/
cpso/lcco/lcco.html

Junto con la Clasificación Dewey y la CDU, uno de los mayores sistemas de clasificación universal. En el web se puede acceder a las clases “top” y de allí a sus respectivas subclases pero no más allá. No consultable. Usa el software Lexico.

LC thesaurus for graphic materials I (TGM I)
http://lcweb.loc.gov/rr/print/tgm1

Creado para la indización y catalogación de imágenes y materiales gráficos. Incluye las relaciones estándar de un tesauro. Consultable. Usa el software Lexico.

LC thesaurus for graphic materials II (TGM II)
http://lcweb.loc.gov/rr/print/tgm2
Esta segunda parte se enfoca más hacia las características de los materiales gráficos. Consultable. Usa el software Lexico.

Lexical freenet
http://bobo.link.cs.cmu.edu/
dougb/lexfn

Permite, por ejemplo, introducir dos términos cualquiera: comida y sequía. Procesa la posible relación entre ellos y ofrece como respuesta el “camino conceptual más corto entre ambos”. En este caso: comida, comer, cosecha, sequía. Utiliza las relaciones semánticas de Wordnet y los análisis estadísticos aplicados a grandes corpora. Mantenido por la Carnegie Mellon University (igual que The semantic rhyming dictionary).

Mesh (Medical subject headings)
http://www.nlm.nih.gov/mesh/mtrees.html

U. S. National Library of Medicine. Conjunto de árboles jerárquicos de términos que cubre todas las disciplinas médicas. Puede accederse a él online o bien cargarse. En la versión online no hay muchos enlaces ni más relaciones que NT-BT indicadas por indentación. 18.000 términos. Se usa para indexar Medline, Aidsline, Cancerline, etc.

Nasa thesaurus
http://www.sti.nasa.gov/
thesfrm1.htm

Hasta hace poco de acceso público.

Oecd macrothesaurus
http://www.darmstadt.gmd.de/
~probst/thesa

http://info.uibk.ac.at/info/
oecd-macroth

Inglés/español/francés/alemán. Ciencias sociales y económicas. Presentación alfabética y jerárquica. Consultable. Permite la construcción de consultas a partir de los descriptores del tesauro.

Plumb design visual thesaurus
http://www.plumbdesign.com/thesaurus

Este tesauro visual accede a Wordnet para presentar gráficamente las relaciones entre palabras. Haciendo clic en cualquiera de las palabras se mueve hacia el centro y muestra sus relaciones (contexto. Árboles hiperbólicos de Xerox). Medios gráficos para ajustar varios parámetros. P. ej.: qué tipo de términos relacionados se quiere ver. Lento.

Roget’s thesaurus
http://www.thesaurus.com
Versión del Roget basada en clases con presentación alfabética y posibilidad de consulta. Lento. Se pueden buscar palabras relacionadas con una clase o subclase.

The semantic rhyming
dictionary

http://www.link.cs.cmu.edu/
dougb/rhyme.html

Muy curioso. Además de ofrecer una rima a cualquier término inglés que el usuario proponga, presenta tipos de relaciones muy interesantes. Por ejemplo: “rima perfecta”, “homófonos”, “correlatos semánticos”, “sinónimos”, etc.

WordNet 1.6 en el www
http://www.cogsci.princeton.
edu/~wn

La nueva versión del Tesauro del idioma inglés de Princeton.

Está en proyecto un tesauro multilingüe financiado por la UE y con participación de universidades españolas como la Uned: EuroWordNet. Se puede encontrar en el web de la Universidad de Amsterdam: http://www.uva.nl/~ewn/

Semántica, xml y VHG

En el www no hay actualmente normas para su control. Los terminólogos han propuesto soluciones basadas en sgml, como por ejemplo la especificación Martif: norma ISO Fdis 12200-1, que utiliza sgml junto a categorías de datos bien definidas para su intercambio (ISO Fdis 12620).

Xml es muy adecuado para el intercambio de terminología vía www. VHG (virtual hyperglossary) es una especificación para información terminológica diseñada con xml que se basa en los nombres y definiciones de clases de datos uniformes de la norma ISO Fdis 12620. Su principal objetivo es posibilitar el intercambio de datos terminológicos a través del web para que puedan ser reutilizados sin perder coherencia ni estructura (contexto).

VHG es independiente de cualquier plataforma o convención y muy interoperativo, ya que es compatible con la mayoría de las iniciativas actuales del W3C (World Wide Web Consortium) sobre xml.

Xml sólo proporciona una sintaxis para las etiquetas en general, lo que significa que no tienen semántica. Ofrece la gran ventaja de que cualquier autor puede desarrollar las suyas propias, pero también el inconveniente de que se requieren nuevos métodos para dotarlas de una semántica coherente. Por ejemplo, la etiqueta <semema> no tiene más sentido para una máquina que el que pueda interpretar sobre su sintaxis: signos preestablecidos, definición de la etiqueta en una DTD (document type definition), etc.

Hay tres métodos para dotarlas de una semántica:

  1. Hojas de estilo XSL (extensible style language).
  2. Software para elementos. Por ejemplo la combinación de xml y Java de modo que la semántica de un conjunto de etiquetas esté codificada en este último y, por lo tanto, sea accesible para máquinas y no para humanos.
  3. Convertir las etiquetas en hiperenlaces hacia glosarios u otros instrumentos terminológicos que sumen su valor sintáctico, su semántica y su posición en una estructura (contexto). Estos hiperenlaces se realizarían con Xlink, que ofrece muchas más posibilidades que el mecanismo html. En definitiva, esto es lo que ofrece VHG3.

Tesauros html

Su mayor aportación es la capacidad hipertextual —aunque mínima a causa de la limitada potencia de su mecanismo de vínculos— y la idea de traducir a hiperenlaces las relaciones entre los términos de un tesauro.

Un tesauro html de cierto tamaño es difícil y costoso de mantener. Simplemente la tarea de actualizar periódicamente los enlaces —algo vital en este tipo de herramientas terminológicas— supone un gasto de tiempo difícil de amortizar. Además, hay una serie de razones por las que distan de ser funcionales:

  1. Es complicado automatizar los procesos.
  2. No es fácil su validación, ya que html no es una especificación con una sintaxis rígida.
  3. No es ampliable y no se pueden, por ejemplo, crear etiquetas para expresar relaciones terminológicas.
  4. No estructura la información, sino que solamente le asigna un formato de presentación. Esta única razón sería suficiente para afirmar que html no es una norma adecuada para implementar tesauros.
  5. Dificulta la reutilización y el intercambio de datos.
  6. Html, “per se”, no es dinámico a pesar de Java, Javascript, Dhtml, html 4.0, DOM (document object model), etc.
  7. No es adecuado para tratar objetos.
  8. Las especificaciones html cambian constantemente y dependen en buena medida de los intereses comerciales de los fabricantes de los navegadores Internet explorer y Netscape, principalmente.

Por todas estas razones, los tesauros creados con este lenguaje que busquen rentabilidad online, parecen destinados a emigrar a otros formatos capaces de aportar la inteligencia a la información que ofrecen como, por ejemplo, xml, sgml, etc.

Bases de datos terminológicas en sgml

Se pueden relacionar fácilmente los tesauros y las llamadas bases de datos terminológicas —cuyo acrónimo en inglés es TDBs—. Desde el punto de vista de sgml (es el que se ha tratado de adoptar en la elaboración del estándar xml) un documento puede ser visto y tratado como una base de datos. Aquel que contenga glosarios se compondría de entradas terminológicas, las cuales se refieren a un solo concepto que se designa mediante términos interrelacionados pertenecientes a dominios o subdominios específicos. Además de alimentar TDBs, esta clase de información puede servir para confeccionar diccionarios, vocabularios técnicos, léxicos y, por supuesto, tesauros automáticos.

AMS Clasificación de materias matemáticas.
http://www.ams.org/msc/home.html

Call (Center for Army Lessons Learned). Diccionario y tesauro militar EUA.
http://call.army.mil/call/thesaur/index.htm

Catie thesaurus (Community aids treatment information exchange).
http://www.catie.ca/thesaurus.nsf

CPV (Common procurement vocabulary). Clasificación de bienes y servicios en la UE. Once idiomas.
http://simap.eu.int/ES/pub/src/welcome_ES.htm

CSQuest-computer engineering concept space.
http://ai.bpa.arizona.edu/html/csquest

Dendronomicon. Índice jerárquico de descriptores de news.
http://twinbrook.cis.uab.edu:70/Classy.80

Dtic thesaurus. Militar.
http://www.dtic.mil/stinet/str/indexthes.html

Glin (Global legal information network thesaurus). LOC. Legislación. Usa el software Lexico.
http://lcweb2.loc.gov/glin/indxhlp.html
http://lcweb2.loc.gov/glin/mdbquery.html

Grants keyword thesaurus. Becas para investigadores.
http://www.rams.com/keyword.htm

Hasset (Humanities and social science electronic thesaurus).
http://dasun1.essex.ac.uk/services/nhasset.html

Ingrid library thesaurus. Universidad de Tartu, en Estonia.
http://ingrid.utlib.ee/thesaurus.html

ITS thesaurus. (Intelligent transportation systems).

http://www.nas.edu/trb/about/itsthes.html

Feminist science fiction, fantasy and utopia thesaurus.
http://www.wenet.net/~lquilter/femsf/thesaurus.html

LIV. (Legislative indexing vocabulary). LOC. Relaciones TG, TE, TR, USE. Usa el software Lexico.
http://www.loc.gov/lexico/liv/brsearch.htm

Multilingual egyptological thesaurus. Facetado. También en español.
http://www.ccer.ggl.ruu.nl/thes

Naics (North American industry classification). México, Canadá y EUA.
http://www.census.gov/epcd/www/naics.html

Nuclear regulatory commission thesaurus.
http://www.pmei.com/nrc

Popin (Population multilingual tesaurus). Mantenido por el Cicred (Committee for international cooperation in national research in demography).
http://www.cicred.ined.fr/thesaurus/thesaurus_a

PTO. Clasificación de patentes EUA.
http://sunsite.unc.edu/patents/intropat.html

Scop (Structural classification of proteins).
http://scop.mrc-lmb.cam.ac.uk/scop

Seattle city clerk thesaurus. De carácter administrativo, buena presentación.
http://clerk.ci.seattle.wa.us/~public/newtoc.htm

Tesauro Claridge de la construcción.
http://liswww.fste.ac.cowan.edu.au/Courseware/IST2221/Coursework/projhtm/sharon/thes.htm

Tesauro de arte y arquitectura. Facetado.
http://www.ahip.getty.edu/aat_browser

Tesauro de astronomía. Inglés, francés, alemán, italiano y español.
http://msowww.anu.edu.au/library/thesaurus

Tesauro de ciencias de la información.
http://www.cisti.nrc.ca/irc/thesaurus/information_systems.html

Tesauro de cocina. Relaciones curiosas (p. ej: sustitutos).
http://www.northcoast.com/~alden/cookhome.html

Tesauro de nombres geográficos. Cerca de 1.000.000 términos geográficos.
http://www.ahip.getty.edu/tgn_browser

Tesauro histórico de la lengua inglesa.
http://www.arts.gla.ac.uk/EngLang/thesaur/homepage.htm

Tesauro Spin. Becas para investigadores.
http://pc1.osr.lsu.edu/cgi-bin/imagemap.exe/osrmap?136,282

Thésaurus du Monde diplomatique. Sobre el periódico del mismo nombre.
http://www.ina.fr/CP/MondeDiplo/Thesaurus/thesaurus.fr.htm

Umweltklassifikation des umweltbundesamtes. Agencia alemana del medioambiente.
http://www.umweltbundesamt.de/uba-datenbanken/klassi.htm

Umweltthesaurus/environmental thesaurus. Alemania, Suiza y Austria. Aprox. 30.000 términos (la versión completa se puede bajar) y 8.500 la versión online.
http://udk.bmu.gv.at/

Virtual hyperglossary (VHG™).
http://www.VHG.org.uk/

Wordsmyth English dictionary-thesaurus.
http://www.lightlink.com/bobp/wedt

La Library of Congress mantiene una página con enlaces a todos sus tesauros en:
http://lcweb.loc.gov/lexico

La descripción TEI de esta categoría de datos fue conocida en primera instancia como TIF (terminology interchange format) y estaba pensada, sobre todo, para permitir a los usuarios de distintas TDBs el intercambio de registros. Esta concepción tiene una gran importancia, pues su estructura varía enormemente de un formato a otro. Quien utiliza estos datos necesita imperiosamente una forma flexible de intercambiarlos para evitar la duplicación de esfuerzos y para acceder al máximo número de fuentes de información especializada.

Físicamente, el medio de exportación para grandes cantidades de datos heterogéneos parece ser el www. La necesidad de un formato integrador se hace todavía más patente, y una de las razones por las que podría basarse en xml es que es un estándar desarrollado específicamente para este contexto.

Algunas de las numerosas dificultades para el intercambio de datos terminológicos provienen de las diferencias de estilo en la confección de entradas y de los cambios en el nivel de detalle usado para clasificar los elementos de datos (unidades mínimas e indivisibles de información). Además hay que tener en cuenta las diversas bases de datos, especificaciones, software específico, paquetes integrados, reglas, normas de facto, versiones de normas, etc.

 

Para la TEI la unidad básica de gestión es la entrada terminológica, que documenta cierta información relativa a un concepto. Generalmente contiene, al menos, un término al que se añaden ciertos datos de tipo descriptivo y administrativo concernientes a él y sus relaciones con otros elementos. Es importante observar las diferencias y similitudes entre la entrada terminológica y el descriptor de un tesauro. Es muy probable que en el desarrollo de instrumentos terminológicos xml se tengan muy en cuenta las orientaciones basadas en la experiencia sgml en general, y la TEI en particular.

Un ejemplo de ello, en inglés y alemán, es:

Subject field: appearance of materials.

English term: opacity. Grammatical information, part of speech. English term: noun. Definition, English term: degree of obstruction to the transmission of visible light. Bibliographical source, English term information: Astm standard E284. Responsability for English term information: technical committee E12.

German term: opazität. Grammatical information, part of speech. German term: noun. Grammatical information, gender, German term: feminine. Definition, German term: Mass für die Lichtdurchsichtigkeit. Bibliographical source, German term information: HFdn1983-382. Responsibility for German term information: DIN Technical committee for paper products.

Con el objetivo de conseguir cierta normalización e integración entre los diferentes recursos terminológicos, la TEI ha llevado a cabo varios estudios empíricos. Intenta con ello reducir la gran variedad de elementos de datos existentes en una serie (relativamente pequeña) de elementos y atributos sgml que expresarían nociones comunes a la mayoría de los esfuerzos hechos en este campo.

En el marcado de estos datos hay tres cuestiones que constituyen un núcleo de elementos no flotantes: <term>, <otherForm> y <descrip>. Éstos son especificados por la TEI para bases de datos terminológicas y se trata de elementos fijos, que deben incluirse en la propia entrada. A su vez, todos los restantes son flotantes (pueden aparecer o no), por ejemplo: <admin>, <note>, <gram>, <bibl>, <biblFull>, <date>, <table>, <formula>, <figure> o los elementos de enlace <ptr>, <xptr> (de donde la especificación XLink sacó sus Xpointers), <ref> y <xref>.

Además, cada uno de los elementos mencionados tiene sus propios delimitadores como: type, responsibility, gen, num, domain, subdomain, created, updated, etc. Existen también ciertas reglas de anidación y combinación de elementos flotantes y no flotantes. Un ejemplo de etiquetado quedaría de la siguiente manera:

<!— Ejemplo de entrada terminológica 2 —>

<termEntry>

<admin type=‘domain’> appearance of materials </admin>

<tig lang=en>

<term> opacity </term>

<gram type=pos> n </gram>

<descrip type=’definition’> degree of obstruction to the transmission of visible light </descrip>

<ptr type=’bibliographic’ target=’ASTM.E284’>

<admin type=’responsibility’ resp=’ASTM E12’></admin>

</tig>

<tig lang=de>

<term> Opazit&auml;t </term>

<gram type=pos> n </gram>

<gram type=gen> f </gram>

<descrip type=’definition’> Ma&szlig; f&uuml;r die Lichtdurchsichtigkeit </descrip>

<ref type=’bibliographic’ target=’HFdn1983’> p. 383 </ref>

<admin type=’responsibility’ resp=’DIN TC for paper products’></admin>

</tig>

</termEntry>

En cuanto a las relaciones de jerarquía entre términos, elementos, etc., en esta especificación vienen marcadas por los siguientes atributos:

— Group: referencia el grupo (término y elementos) al cual debe ser asociado.

— Depend: indica el elemento padre al que debe ser asociado el término.

— GrpPtr: es el indicador de grupo (término y elementos) al cual debe ser relacionado el término al especificar su identificador.

— DepPtr: indica el elemento padre al que debe ser vinculado el término al especificar su identificador.

Basta un análisis superficial para darse cuenta de que no es suficiente para establecer las relaciones de jerarquía tan importantes a la hora de elaborar un tesauro o de diseñar la estructura arbórea de un documento. Sin embargo, a pesar de que la TEI solucione esto con su especificación para enlaces, xml tiene la ventaja de permitir la creación de etiquetas, lo que le dota de una gran flexibilidad.

Xml aplicado al desarrollo de instrumentos terminológicos

Este lenguaje de etiquetas fue ideado para estructurar la información de los documentos electrónicos del www. Generalmente éstos poseen estructura cuando, además de contenido (palabras, imágenes, etc.), tienen también cierta metainformación sobre la función que desempeñan. Por ejemplo, si aparece encabezando el documento, adquiere un significado diferente del que obtendría si se encuentra en una nota a pie de página4.

Un lenguaje de etiquetas es un mecanismo para identificar la/s estructura/s que presenta la información dentro de un documento. La especificación xml define una forma normalizada de añadirlas a los documentos.

Xml en sustitución de html. En html la semántica de las etiquetas y su conjunto son fijos. <h1> indica siempre un encabezamiento, y la etiqueta <blablabla> nunca tiene sentido. El W3C, en colaboración con los productores de navegadores, ha estado trabajando constantemente: ampliando la definición de html, diseñando nuevas etiquetas adaptadas a una tecnología que cambia continuamente y proponiendo soluciones a la presentación de los documentos en el www mediante las stylesheets (hojas de estilo). Sin embargo, este esfuerzo siempre se ha visto restringido por las etiquetas que las dos principales empresas productoras han decidido, o no, implementar.

Xml no especifica una semántica ni tampoco un conjunto de etiquetas. De hecho, es en realidad un metalenguaje para describir expresiones de marcado y proporciona un medio para definir etiquetas y las relaciones estructurales entre ellas. Si no hay un conjunto predefinido no puede haber una semántica preconcebida, que será determinada por las aplicaciones que lo procesen o las hojas de estilo asociadas a él.

Xml en lugar de sgml. La definición de xml es la de un perfil de aplicación de sgml. Ésta ha sido la norma que se ha utilizado de forma independiente a las grandes empresas informáticas durante más de una década para mantener y gestionar grandes cantidades de documentación estructurada. Uno de sus problemas es que no se ha adaptado bien al intercambio de documentos a través del www.

Si xml se entiende como un perfil de aplicación de sgml significa que cualquier sistema conformado para éste debe ser capaz de gestionar documentos creados con aquel. Además, tampoco se requiere un sistema ajustado para el 100% de sgml puesto que xml es una forma muy restringida de él.

Aunque un sistema sgml puede gestionar documentos xml (no al contrario), los tratará de forma ligeramente diferente. Un ejemplo es el espacio en blanco junto a las etiquetas. En ambos tipos de documentos puede darse esta situación, sin embargo, un parser sgml reacciona ante él interpretándolo, y no como uno xml que, simplemente, lo ignora. De estos detalles se puede deducir la gran diferencia en complejidad y posibilidades entre ambos.

Proyectos terminológicos TEI accesibles vía www:

  • African languages lexicon project (Allex) http://svenska.gu.se/~ridings/allex.html
  • Gramáticas para analizar diccionarios http://www.cs.umd.edu/users/ericp
  • Thesaurus musicarum italicarum http://candl.let.ruu.nl/Research/tmi/main.htm
  • Codificación en el diccionario Mitre http://www-tei.uic.edu/orgs/tei/app/mitre.html
  • Electronic thesaurus linguae latinae http://www.cs.usask.ca/faculty/devitoeTLL/ach95poster.html

¿Por qué y para qué se ha creado xml? Para que fuera posible intercambiar documentos muy estructurados a través del www y porque las únicas alternativas viables, html y sgml, no son prácticas para este propósito. El primero no es capaz de organizar un documento, y además, sus etiquetas tienen una semántica propia. Por su parte, sgml puede estructurar la información de los documentos, pero es demasiado complicado para implementarlo en un navegador.

Puesto que xml se ha diseñado para intercambiar contenido estructurado a través del www, no es razonable prever que pueda algún día llegar a reemplazar a sgml. Por lo tanto, para ser una solución ágil y práctica carece de muchas características valiosas de sgml. Son estas cualidades y la amplitud mucho mayor de éste lo que lo convierten en una solución más satisfactoria que xml para la creación y almacenamiento (a largo plazo) de documentos de estructura compleja. Para muchas organizaciones, filtrar las bases de datos sgml a xml con el fin de intercambiar información, y de nuevo hacerlo a la inversa para almacenarla y gestionarla, se convertirá en una actividad cotidiana e imprescindible5.

Objetivos de xml. Principalmente son los siguientes:

  • Se ha creado para el www.
  • Sobre xml se puede desarrollar una gran cantidad de aplicaciones, aunque el enfoque inicial fuera el intercambio de información estructurada en internet.
  • Compatibilidad con sgml.
  • Los programas que lo procesen no presentarán grandes dificultades de desarrollo.
  • Se intenta mantener el mínimo número posible de características opcionales del estándar por motivos de compatibilidad.
  • El código de los documentos xml debe ser inteligible para los usuarios, y nunca desvirtuar el propio contenido.
  • Su desarrollo debe ser, por necesidad, más rápido que el de otras normas.
  • El diseño debe ser formal y de la máxima concisión. Esto significa, esencialmente, que xml debe expresarse en Ebnf (extended backus-naur form) para que sea fácil de compilar. Éstas son un conjunto de reglas, llamadas de producción, y cada una define un fragmento específico de sintaxis. Un documento es válido si puede ser reducido a una única regla específica mediante la aplicación de otras.

Un ejemplo que nada tiene que ver con xml en sí, sino con la filosofía con la que ha sido diseñado es:

  1. Palabra ::= consonante + vocal + consonante.
  2. Consonante ::= [^aeiou].
  3. Vocal ::= [aeiou].

La regla 1 dice que una palabra es una consonante seguida de una o más vocales, continuadas por otra consonante. La número 2 dice que una consonante es cualquier letra diferente de “a, e, i, o, u”. La 3 dice que una vocal es cualquiera de las letras “a, e, i, o, u”. Su sintaxis exacta, el significado de los símbolos, como los corchetes, se interpreta según la norma que se use (xml, por ejemplo).

Según el ejemplo anterior, ¿“ser” podría considerarse como una palabra?

  1. A la letra “s” le sigue una “e” y, a ésta, una “r”.
  2. “S” es una consonante según la regla 2, por lo tanto “ser” es consonante, “e”, ”r”.
  3. “E” es una vocal según la número 3, por lo tanto: consonante, vocal, “r”.
  4. Por la regla 2 otra vez, “ser” es: consonante, vocal, consonante. Según la 1 es una palabra.

Aplicándolas de nuevo, “cal”, “loar”, “sol”, “baúl” e incluso “tuuuuuuut” se consideran palabras y, sin embargo, “rojo” no. Esto es así porque la secuencia: consonante, vocal, consonante, vocal, no está prevista por la regla Ebnf que se ha usado como ejemplo. El núcleo de xml consiste en una gramática Ebnf de aproximadamente 80 reglas, aunque son bastante más complicadas que las del ejemplo. Un parser xml aplica el mismo tipo de análisis para determinar si el documento que está analizando es del tipo xml correcto o no, sintácticamente hablando.

 

  • Los documentos xml deben ser fáciles de crear. Aunque probablemente aparecerán pronto todo tipo de editores en el mercado, de momento se pueden generar directamente desde un editor de texto.

Especificaciones de xml. Las más importantes son:

  • Xml: define su sintaxis.
  • XLink indica una forma estándar de representar enlaces entre recursos. Además de uniones simples, como los que implementa html, ofrece la posibilidad de vincular, por ejemplo, muchos recursos entre sí.
  • XSL: define la presentación de los documentos xml.
  • XUA (xml user agent): es usado para la normalización de los agentes usuarios de xml: navegadores, sistemas “push”, etc.

Gráfico 1

DTDs. Un gran porcentaje de la especificación xml trata varios tipos de declaraciones permitidas y éstas provienen de las DTDs de la norma sgml. Una de las grandes virtudes de xml es que permite la creación de nuevas etiquetas. Sin embargo, un documento en las que ocurran en un orden completamente arbitrario carece de sentido para las aplicaciones. Pueede observarse este ejemplo:

<cliente>

<apellido>González</apellido><precio>200</precio>

<nombre><nom>Hortensia</nom><fecha>19 de mayo, 1998</fecha></nombre>

<pedido><item><numero>5</numero></item><suma/></pedido>

<producto>Lechuga</producto>

<producto>Calabacín</producto>

<item><numero>2</numero><precio>120</precio></item>

</cliente>

Esta claro que un documento así no tendría lógica. Sin embargo, desde un punto de vista estrictamente sintáctico (como expresión Ebnf), es correcto. Por lo tanto, si se desea que tenga sentido debe haber ciertas restricciones en la secuencia y forma de anidar las etiquetas. Esas limitaciones pueden expresarse mediante una declaración, que en general permite a un documento comunicar al parser metainformación sobre la estructura de su contenido, e incluiría:

  • La secuencia de etiquetas en el documento y la forma de anidarlas.
  • Los tipos de atributos, sus valores y los establecidos por defecto.
  • Los nombres de archivos externos que se hallen referenciados en el documento e información sobre si contienen, o no, formato xml.
  • Los formatos sobre datos no xml que puedan aparecer en el documento.
  • Las entidades presentes.

En otras palabras, la DTD es lo que convierte el código xml del anterior ejemplo en la estructura arbórea que representa el gráfico 1.

En xml hay cuatro clases de declaraciones: de elemento, de listas de atributos, de entidad, y de notación.

1. Declaraciones de elemento: identifican sus nombres y la naturaleza de su contenido. Un ejemplo podría ser el siguiente:

<!element pedido (item+, suma?)>

Su función es identificar al elemento llamado pedido. Su modelo de contenido sigue al nombre de elemento y define lo que puede contener. En este caso debe admitir un “item” y una “suma”. Las comas entre ellos indican que deben ocurrir sucesivamente. El signo “+” significa que puede repetirse, pero que forzosamente debe ocurrir al menos una vez. “?” indica que “suma” es un elemento opcional. Un nombre sin puntuación debe ocurrir exactamente una vez.

Las declaraciones referentes a todos los elementos se presentan a un procesador xml que se encarga de examinar la validez del documento. Además de los nombres de elementos, el símbolo #pcdata (parseable character data) se reserva para indicar cadenas de caracteres. A los elementos que tienen dentro otros y, además, contenido pcdata se les denominan mixtos.

En el ejemplo anterior podría ocurrir algo como:

<!element cliente (#pcdata | nombre | fecha | pedido+) *>

La barra vertical indica una relación de tipo “or”, el asterisco señala que el contenido es opcional (puede ocurrir una o más veces). Por lo tanto, según esta definición un cliente puede contener ninguna o más veces una cadena de caracteres y los demás elementos indicados: nombre, fecha, pedido. Todos los modelos de contenido que incluyan pcdata deben tener la siguiente forma: pcdata primero y todos los elementos que le sigan deben estar separados por barras verticales. El grupo entero debe ser de carácter opcional.

Existen otras dos estructuras de contenido posibles: empty indica que el elemento está vacío (y por lo tanto tampoco tiene una etiqueta de final). Any indica que en ese elemento se permite cualquier tipo de contenido y no exclusivamente pcdata.

Sobre el documento que se ha presentado como ejemplo se podría hacer una declaración parecida (gráfico 2).

Gráfico 2

2. Declaraciones de atributo: identifican qué elementos pueden tenerlos, los que pueden tener como válidos, los valores que pueden presentar y el establecido por defecto en cada uno. Desarrollando un poco más el ejemplo anterior, una declaración de esta clase podría ser:

<!attlist cliente

nombre id #required

debe cdata #implied

clase (buencliente | malcliente) “buencliente”>

Aquí, el elemento cliente tiene tres atributos: “nombre”, que es de tipo “id” y obligatorio; “debe”, que es una cadena de caracteres “cdata” y no es obligatorio y “clase”, que puede ser buencliente (por defecto) o malcliente.

Cada uno de los atributos en la declaración se compone de tres partes: un nombre, un tipo y un valor por defecto. El usuario puede elegir cualquier nombre, pero no es posible repetir los de atributo en el mismo elemento.

Pueden encontrarse los siguientes tipos posibles de atributos.

  • Cdata: son cadenas de texto y en ellos se reconocen las etiquetas. No se deben confundir con las secciones cdata.
  • Id: su valor debe ser un nombre. Todos los usados en un documento deben ser diferentes. Los elementos sólo pueden tener un único atributo id.

Además hay otros como: idref, entity y nmtoken.

Los valores por defecto pueden ser los siguientes.

  • #Required: debe presentar un valor explícito cada vez que el elemento ocurra.
  • #Implied: el valor del atributo no se requiere y no establece ninguno por defecto. Si en consecuencia no se especifica, el procesador xml trabajará sin él.
  • Valor: se le puede dar al atributo un valor por defecto. No se requiere uno para cada elemento del documento. Por eso, si no hay valores presentes se tomará éste.
  • #Fixed valor: en una declaración de atributo se puede especificar cuál tiene un valor fijo. En este caso, si el atributo ocurre debe tener uno especificado. Esto se puede utilizar para asociar cierta “semántica” a un elemento.

3. Declaraciones de entidad: permiten relacionar un nombre con algún otro fragmento del documento: datos regulares, partes de DTDs o archivos externos.

<!entity est “estructura jerárquica”>

<!entity antoniotes system “/antonio/iwe/xml/tesauro.xml”>

<!entity marikegif system “/dibujos/marike.gif” ndata gif87a>

Hay tres clases de entidades:

  • Entidades internas: la primera del ejemplo es de esta clase. Cada vez que se escriba “est” se insertará en el documento la cadena estructura jerárquica. Permiten definir abreviaturas para el texto que aparece a menudo o el que se espera que cambie.

    La especificación xml define para sí misma cinco entidades internas:
    1. “&lt”: produce <.
    2. “&gt”: produce >.
    3. “&amp”: produce &.
    4. “&apos”: produce ‘.
    5. “&quot”: produce “.
  • Entidades externas: la segunda y tercera del ejemplo son de este tipo. Tecleando “antoniotes” se insertará el contenido del archivo: /antonio/iwe/xml/tesauro.xml en el lugar del documento donde se halla procesada dicha llamada. El procesador xml analizará su contenido como si hubiera sido tecleado en lugar de la referencia de entidad.

    La entidad indicada con “marike.gif” es también externa, pero su contenido es binario, así que sólo podrá usarse como valor de un atributo “entity”. El procesador xml pasará esta información a una aplicación pero no intentará gestionar su contenido.

    Estas entidades permiten a un documento xml referirse a un archivo externo. Si éste contiene texto se insertará en lugar de la referencia y será procesado como parte del documento. Si son datos binarios no serán tomados en cuenta, sino pasados a una aplicación.
  • Entidades paramétricas: pueden ocurrir solamente en la DTD. Se identifican mediante “% ” (porcentaje + espacio) precediendo a su nombre. Cuando el parser llega a ella, todo lo que tenga asociado se expande en la DTD y es procesado como parte suya.

4. Declaraciones de notación: identifican tipos específicos de datos externos. Esta información se pasa a la aplicación correspondiente. Por ejemplo:

<!notation gif87a system “gif”>

¿Cuándo es necesaria una DTD? Como se ha visto, el contenido xml puede procesarse sin ellas. Sin embargo, hay algunos casos en los que se hacen necesarias. Un ejemplo curioso es el tratamiento de los espacios en blanco. La regla para los procesadores xml es que son significativos siempre y cuando no haya una declaración que identifique el modelo de contenido.

En general, las aplicaciones donde los datos son editados más o menos manualmente —en oposición a las que filtran la información desde bases de datos—, tarde o temprano necesitarán una DTD si quieren garantizar la estructura. Y dado que lo que ofrece xml es precisamente un modelo para hacerlo, hay que concluir que serán prácticamente imprescindibles, pero nunca obligatorias, en la mayoría de los casos.

Si hay una DTD, se incluye en la primera parte del documento tras las instrucciones de proceso (opcionales) y los comentarios, e identificará el elemento raíz del documento, el cual es imprescindible y engloba a todos los demás y, en consecuencia, todo el contenido.

<?xml version=”1.0” rmd=”internal”?>

<!doctype capítulo system “libro.dtd” [

<!element enlace (#pcdata)*>

<!attlist enlace

xml-link cdata #fixed “simple”

xml-attributes cdata #fixed “href url”

url cdata #required>

]>

<capítulo>...</capítulo>

Este ejemplo referencia una DTD externa: libro.dtd, e incluye una declaración de elemento y otra de atributo para “enlace”, que posee la semántica correspondiente a un vínculo simple de la especificación XLink.

Para determinar si es válido, el procesador xml debe leer la DTD entera, ya sea interna y/o externa. Para algunas aplicaciones puede ser suficiente con leer la primera, en el caso de que no sea requerida dicha autenticidad.

Se puede establecer si las aplicaciones deben o no averiguar esta validez en el apartado RMD (required markup declaration) que aparece en la primera instrucción junto a la versión de xml. RMD puede ser “internal” (como en el ejemplo), “all” o “none”. Con “internal” sólo se procesarán las DTDs internas. Con “all” tanto las internas (primero) como las externas. Esto es importante ya que si las declaraciones contienen información duplicada, en xml la primera tiene preferencia. Por último, con ”none” no se tiene en cuenta ninguna.

Por lo anterior se deduce que algunos documentos son válidos y otros no. En general hay dos categorías en xml: bien formados, solamente si obedecen la sintaxis xml (véase Ebnf), y válidos, cuando atiende a las restricciones de su DTD.

XLink. Es la especificación semántica para enlaces que tiene xml y posee algunas características realmente interesantes a la hora de diseñar un tesauro para el www. Anteriormente ya se comentó que la contribución más significativa de los tesauros html fue la idea de convertir las relaciones semánticas en hiperenlaces.

Con XLink, un enlace expresa la relación entre recursos, que son entendidos como cualquier lugar al cual se hace referencia. Por ejemplo, cualquiera identificado mediante “id” o el contenido de un elemento de enlace. La naturaleza exacta de la relación entre ellos dependerá de la aplicación que la procese y de la información semántica que se ofrezca en ella.

Dos de sus características más destacadas son:

  • Posibilita los enlaces extendidos (herencia de la TEI) que pueden conectar más de dos recursos.
  • Introduce los punteros extendidos o Xpointers (también herencia de la TEI), un método sofisticado para localizar recursos. Puesto que xml no tiene un conjunto fijo de elementos, su nombre no puede usarse para localizar enlaces. En lugar de eso, los procesadores xml lo identifican al reconocer el atributo xml-XLink.

Hay otros atributos usados para suministrar al procesador información adicional. Por ejemplo show y actuate permiten ejercer cierto control sobre el comportamiento del enlace. El primero determina si el recurso referenciado debe anidarse en el documento actual, remplazarlo o ser presentado en una nueva ventana cuando se active el enlace. Actuate especifica cómo se activa un vínculo: automáticamente cuando el procesador llega a él o sólo cuando ha sido previamente seleccionado por el usuario.

 

Por supuesto, algunas aplicaciones requieren un control mucho más exacto del comportamiento de las uniones. Éste es el caso de un tesauro xml si se tiene en cuenta que las relaciones entre sus términos son indicadas mediante enlaces. Para este tipo de aplicaciones, además de la semántica desarrollada hasta ahora por la especificación XLink, se contemplan espacios normalizados en la estructura de los vínculos, donde expresar semánticas adicionales.

— Enlaces simples (inline): identifican la conexión entre dos recursos, uno de los cuales es el contenido del propio elemento enlace: <link> </link>.

<link xml-link=”simple” href=”localizador”>texto del enlace</link>

El localizador puede ser una URL, una query, un Xpointer, etc., e identifica al segundo recurso.

— Enlaces extendidos: permiten expresar relaciones entre más de dos elementos:

<elink xml-link=”extended” role=”annotation”>

<locator xml-link=”localizador” href=”text.html”>texto</locator>

<locator xml-link=”localizador” href=”not1.html”>notas</locator>

<locator xml-link=”localizador” href=”not2.html”>más notas</locator>

<locator xml-link=”localizador” href=”crit.html”>crítica</locator>

</elink>

Este ejemplo muestra cómo se pueden indicar las relaciones entre una obra, sus notas y la crítica que ha recibido. Es importante la idea de que el enlace extendido se halle separado de los recursos que engloba. Su semántica depende también de la aplicación que los procese.

 

Además pueden ser inline, con lo cual el contenido del elemento enlace es diferente de los localizadores y participa en el vínculo como una fuente de información más. El ejemplo anterior es del tipo out-of-line porque <elink></elink> no usa su contenido como recurso.

— Punteros extendidos (Xpointers): Se parecen al mecanismo id/idref de sgml —de la simplificación de la cual se extrajo el anchor html: #fragmento—. El recurso al que se quiere enlazar está definido como un ancla en el documento destino y, por lo tanto, es localizable. De ese modo sólo hay que referenciarlo correctamente.

Los Xpointers de xml toman prestados conceptos importantes de HyTime y de la TEI, y ofrecen una sintaxis que permite encontrar un recurso a través del árbol de elementos del documento que lo contiene.

Además de la selección por elemento, permiten la elección por “id”, valor de atributo y coincidencia de una cadena de texto.

— Grupos de enlaces extendidos: Los vínculos out-of-line provocan que un procesador xml deba gestionar más de un archivo para presentar correctamente el documento hipertexto. En el ejemplo anterior, <elink></elink> debería cargar, por lo menos, el texto y el documento que contenga el enlace extendido.

XLink define sus grupos para resolver esta cuestión. Al cargarlos se comunica al procesador con qué documentos debe hacerlo, el orden, etc. Pueden usarse recursivamente, y uno de sus atributos, “step”, sirve para especificar el límite de profundidad de la recursión6.

Ejemplo de tesauro ISO-2788 convertido en xml

Han existido muchas propuestas de tipos de relaciones entre términos para tenerse en cuenta en la realización de estas herramientas terminológicas. Las más ampliamente aceptadas son las especificadas en la norma ISO-2788 para tesauros monolingües. Ésta equivale la UNE 50-106-90, Aenor 1990, que especifica las siguientes relaciones: SN (Scope note), USE, UF (Used for), TT (Top term), BT (Broad term), NT (Narrower term) y RT (Related term).

El mejor ejemplo de su aplicación se puede ver en la Library of Congress subject headings (Lcsh) que se distribuye en formato Usmarc. Para los objetivos de este artículo se puede usar el siguiente caso que seguidamente se desarrollará en xml7. Nótese la expresión tipográfica de la jerarquía y que se han empleado las siguientes abreviaturas:

T= término.

TG= término general (TG1, TG2, TG3, TG4).

TE= término específico (TE1, TE2, TE3, TE4).

TR= término relacionado.

Ten= término en inglés.

Tde= término en alemán.

Tfr= término en francés.

Titl= término en italiano.

Def= definición.

RA= recursos asociados.

TT Bases de datos.

d/datenbasen e/data bases f/bases de donnees i/basi de dati.

NA Conjunto de datos catalogados adecuadamente para satisfacer una determinada demanda informativa.

TG1 Documentos electrónicos.

TG2 Material no impreso.

TG3 Material de información.

TG4 Información.

TG1 Procesamiento de la información.

TG2 Tecnología de la información.

TG3 Información.

TG3 Tecnología.

TG4 Ciencia y tecnología.

TG1 Servicios de información.

TG2 Difusión de la información.

TG3 Información.

TE1 Bases de datos en cd-rom.

TE1 Bases de datos en línea.

TE1 Bases de datos fuente.

TE2 Bases de datos numéricas.

TE2 Bases de datos textuales.

TE2 Bases de datos textuales-numéricas.

TE1 Bases de datos referenciales.

TE2 Bases de datos bibliográficas.

TE2 Directorios.

TR Almacenamiento de la información.

TR Análisis documental.

TR Archivos.

TR Bancos de datos.

TR Bibliotecas.

TR Centros de documentación.

TR Discos.

TR Elaboración de datos.

TR Programas informáticos.

TR Publicaciones electrónicas.

TR Recuperación de la información.

TR Sistemas de información.

TR Tablones electrónicos de anuncios.

TR Videotexto.

Sobre el ejemplo anterior se propone la siguiente DTD y documento xml, que correspondería a un término concreto (bases de datos) pero cuyo código es aplicable a cualquiera de un tesauro ISO-27888.

<?xml version = “1.0”?>

<!doctype document [

<!element document (termino+) *>

<!element termino (T, TG+, TE+, TR+) *>

<!element T (nombre, traduc?, def, ra?)*>

<!element nombre (#pcdata)>

<!element traduc (Ten, Tde, Tfr, Titl)*>

<!element Ten (#pcdata)>

<!element Tde (#pcdata)>

<!element Tfr (#pcdata)>

<!element Titl (#pcdata)>

<!element def (#pcdata)>

<!element ra (#pcdata)>

<!element TG (TG1+)*>

<!element TG1 (#pcdata | TG2+)*>

<!element TG2 (#pcdata | TG3+)*>

<!element TG3 (#pcdata | TG4+)*>

<!element TG4 (#pcdata)*>

<!element TE (TE1)*>

<!element TE1 (#pcdata | TE2+)*>

<!element TE2 (#pcdata | TE3+)*>

<!element TE3 (#pcdata | TE4+)*>

<!element TE4 (#pcdata)*>

<!element clase (#pcdata)>

<!element TR (#pcdata)>

]>

<document>

<termino>

<T>

<nombre>Bases de datos.</nombre>

<traduc>

<Ten> Data bases.</ten>

<Tde> Daten basen.</tde>

<Tfr> Bases de donnees.</tfr>

<Titl> Basi di dati.</titl>

</traduc>

<def>

Conjunto de datos catalogados adecuadamente para satisfacer una determinada demanda informativa.

</def>

<ra>

http://www...

</ra>

</T>

<TG>

<TG1>Documentos electrónicos.

<TG2>Material no impreso.

<TG3>Material de información.

<TG4>Información</TG4>.

</TG3>

</TG2>

</TG1>

</TG>

<TG>

<TG1>Procesamiento de la información.

<TG2>Tecnología de la información.

<TG3>Información.

<TG4></TG4>

</TG3>

<TG3>Tecnología.

<TG4>Ciencia y tecnología.</TG4>

</TG3>

</TG2>

</TG1>

</TG>

<TG>

<TG1>Servicios de información.

<TG2>Difusión de la información.

<TG3>Información.

<TG4></TG4>

</TG3>

</TG2>

</TG1>

</TG>

<TE>

<TE1>Bases de datos en cd-rom.

<TE2>

<TE3>

<TE4></TE4>

</TE3>

</TE2>

</TE1>

</TE>

<TE>

<TE1>Bases de datos en línea.

<TE2>

<TE3>

<TE4></TE4>

</TE3>

</TE2>

</TE1>

</TE>

<TE>

<TE1>Bases de datos fuente.

<TE2>Bases de datos numéricas.

<TE3>

Enlace del artículo:
http://www.elprofesionaldelainformacion.com/contenidos/1999/octubre/instrumentos_terminologicos_en_el_www_xml.html