9.4: Mundos de descripción

En las dos secciones anteriores hemos considerado las descripciones como objetos diseñados con estructuras particulares y como documentos escritos con sintaxis particulares. Como hemos visto, hay muchas opciones posibles de estructura y sintaxis. Pero estas elecciones nunca se hacen de manera aislada. Así como un arquitecto o diseñador debe trabajar dentro de las limitaciones del entorno construido existente, y así como cualquier autor debe trabajar con sistemas de escritura existentes, las descripciones siempre se crean como parte de un “mundo” preexistente sobre el que cualquiera de nosotros tiene poco control.

En la parte final de este capítulo, consideraremos cómo las elecciones de estructura y sintaxis han convergido históricamente en amplios patrones de uso. A falta de un término mejor, llamamos a estos patrones amplios “mundos. ” “Mundo” no es un término técnico y no debe tomarse de manera demasiado literal: las amplias áreas de aplicación esbozadas aquí tienen una superposición considerable, y hay muchas otras formas en las que uno podría identificar patrones de estructura de descripción y sintaxis. Dicho esto, los tres mundos aquí descritos reflejan patrones reales de forma descriptiva que influyen en las elecciones de herramientas y tecnología. En tu propio trabajo creando y administrando descripciones de recursos, es probable que necesites pensar en cómo tus descripciones encajan en uno o más de estos mundos.

El mundo del procesamiento de documentos

El primer mundo que consideraremos se ocupa principalmente de la creación, procesamiento y gestión de documentos híbridos narrativo-transaccionales como manuales de instrucciones, libros de texto o manuscritos medievales anotados. (Ver El Espectro de Tipo de Documento). Estos son tipos de documentos bastante diferentes, pero todos contienen una mezcla de texto narrativo y datos estructurados, y todos pueden modelarse útilmente como estructuras de árbol. Debido a estas cualidades compartidas, herramientas tan diferentes como el software de publicación, el software de gestión de la cadena de suministro y el software de edición académica han convergido en soluciones comunes basadas en XML. (“El mundo XML” sería otro nombre apropiado para el mundo del procesamiento de documentos.)

Esta convergencia no fue casualidad, porque XML fue diseñado específicamente para abordar el problema de cómo agregar estructura y datos a los documentos “marcándolos. ” XML es el descendiente del Lenguaje de Marcado Generalizado Estándar (SGML), que a su vez descendió del Lenguaje de Marcado Generalizado de International Business Machines (IBM), el cual fue inventado para permitir la producción y gestión de documentación técnica a gran escala. La especificidad del marcado lo hace muy adecuado para representar distinciones de estructura y tipo de contenido en contextos institucionales, donde el alcance, la escala y la vida esperada de organizar sistemas de información implica la reutilización por personas desconocidas para fines imprevistos.

El modelo de datos abstractos subyacente a XML se denomina Conjunto de Información XML o Infoset. El Infoset define un documento como un árbol parcialmente ordenado de “elementos de información. ” Por lo tanto, cada documento XML puede entenderse como un tipo específico de árbol, aunque no todas las estructuras de árbol son expresables como un documento XML. ^[1]

Como discutimos en Inclusiones y Referencias, Figura: Descripciones Vinculadas en una Gráfica.

Implementación XML de un Biblio-gráfico

        <person id="WG.Sebald">Winfried George Sebald</person>
<person id="MR.McCulloch>Mark Richard McCulloch</person>

<book>
    <title>Understanding W.G. Sebald</title>
    <subject idref="WG.Sebald"/>
    <author idref="WG.Sebald"/>
    <author idref="MR.McCulloch"/>
</book>

<book pages="371">
    <title lang="de">Die Ringe des Saturne</title>
    <title lang="en">The Rings of Saturn</title>
    <author idref="WG.Sebald"/>
</book>

<book pages="416">
    <title lang="de">Austerlitz</title>
    <author idref="WG.Sebald"/>
</book>
      

Como cabría esperar, las herramientas y tecnologías en el mundo del procesamiento de documentos están optimizadas para manipular y combinar estructuras de árboles. Una “cadena de herramientas” es un conjunto de herramientas destinadas a ser utilizadas juntas para lograr algún objetivo.

La cadena de herramientas XML

La cadena de herramientas XML es bastante completa. Consta de herramientas para la creación de documentos XML (editores XML), herramientas para expresar documentos lógicos y modelos de datos (DTD, Esquema XML, Lenguaje regular para XML Next Generation (RELAX NG), Schematron), herramientas para transformar documentos XML (XSLT), herramientas para describir “pipelines” de procesamiento de documentos (XProc: An XML Pipeline Language) y herramientas para almacenar y consultar colecciones de documentos XML ( Bases de datos XML, consultadas mediante Lenguaje de Consulta XML (XQuery)). Utilizadas en conjunto, estas herramientas proporcionan medios muy poderosos para trabajar con documentos estructurados en árboles. Los editores XML incorporan conocimientos de DTD, esquemas, transformaciones, hojas de estilo, consultas, bases de datos y pipelines. Las tuberías coreografían las tuberías y las interdependencias involucradas en el procesamiento de un conjunto de datos complejo y la publicación de un resultado útil en uno o más formatos de salida.

Para los programadores que no utilicen la cadena de herramientas XML, otros lenguajes de programación también proporcionan bibliotecas para trabajar con XML. Este hecho ha llevado a algunos a proponer, y a otros a creer, que XML es una especie de formato universal para el intercambio de datos entre sistemas. Sin embargo, los programadores han observado que un Infoset XML aleatorio no se mapea fácilmente a las estructuras de datos que se encuentran comúnmente en muchos lenguajes de programación. “Trabajar con XML” frecuentemente significa traducir de estructuras de árbol XML a estructuras de datos nativas de otro idioma, generalmente significa listas y diccionarios. Esta traducción puede ser problemática y a menudo significa renunciar a muchas de las fortalezas de XML. De la misma manera, hay décadas más prácticas de experiencia trabajando con lenguajes de marcado y publicación institucional que con JSON y RDF.

XML no es una solución universal para todos los problemas posibles. Eso no quiere decir que no sea la mejor solución para una amplia variedad de problemas, incluido el suyo. Para evaluar si las descripciones de sus recursos son, o deberían ser, parte del mundo del procesamiento de documentos, hágase las siguientes preguntas:

• ¿Las descripciones de mis recursos contienen mezclas de texto narrativo, hipertexto, datos estructurados y una variedad de formatos de medios?

• ¿Mis descripciones pueden modelarse fácilmente usando estructuras de árbol, enlaces de hipertexto y transclusión?

• ¿Los vocabularios que necesito o quiero usar están disponibles usando tecnologías XML?

• ¿Necesito trabajar con un cuerpo de descripciones existentes ya codificadas como XML?

• ¿Necesito interoperar con procesos o socios que utilizan la cadena de herramientas XML?

• ¿Necesito publicar mis descripciones de recursos en múltiples formatos desde una sola fuente?

Si la respuesta a una o más de estas preguntas es “sí”, entonces es muy probable que estés trabajando dentro del mundo del procesamiento de documentos, y tendrás que familiarizarte con conceptualizar tus descripciones como árboles y trabajar con ellas usando herramientas XML.

El Mundo de la Web

El segundo “mundo” surgió a principios de la década de 1990 con la creación de la World Wide Web. La web fue desarrollada para atender la necesidad de compartir datos científicos de manera simple y rápida. Por supuesto, ha crecido mucho más allá de ese caso de uso inicial, y ahora es una infraestructura ubicua para todas las variedades de servicios de información y comunicación. (“El mundo de los navegadores” sería otro nombre apropiado para lo que estamos llamando el Mundo Web.)

Los documentos, datos y servicios en la web son conceptualizados como recursos, identificados mediante Identificadores Uniformes de Recursos (URI) y accesibles a través de representaciones transferidas a través del Protocolo de Transferencia de Hipertexto (HTTP). Las representaciones son secuencias de bytes, y podrían ser páginas HTML, imágenes JPEG, datos tabulares o prácticamente cualquier otra cosa transferible a través de HTTP. No importa cuáles sean, las representaciones transferidas a través de la web incluyen descripciones de sí mismas. Estas descripciones toman la forma de pares propiedad-valor, conocidos como “encabezados HTTP. ” Los encabezados HTTP de las representaciones web se estructuran como diccionarios.

Las estructuras de diccionario aparecen muchos otros lugares en la infraestructura web. Los URI pueden incluir un componente de consulta que comience con un? carácter. Este componente se utiliza para fines tales como proporcionar parámetros de consulta para servicios de búsqueda. El componente de consulta se estructura comúnmente como un diccionario, que consiste en una serie de pares propiedad-valor separados por el carácter &. Por ejemplo, el siguiente URI:

      https://www.google.com/search?q=sebald&tbs=qdr:m
    

incluye el componente de consulta q=sebald&tbs=qdr:m. Este es un diccionario con las propiedades q y tbs, especificando respectivamente el término de búsqueda y las restricciones temporales en la búsqueda.

Los datos ingresados en un formulario HTML también se estructuran como un diccionario. Cuando se envía un formulario HTML, los datos ingresados se utilizan para componer el componente de consulta de un URI, o para crear una nueva representación para ser transferida a un servidor web. En cualquier caso, los datos se estructuran como un conjunto de propiedades y sus valores correspondientes.

^[2] Los microformatos son otro método para hacer esto mapeando existentes ^[3]

Las estructuras de diccionario son fáciles de trabajar en cualquier lenguaje de programación, e impregnan varios marcos populares para programar la Web. En los lenguajes de programación utilizados para implementar servicios web, los encabezados HTTP y los parámetros de consulta se mapean fácilmente a estructuras de datos de diccionario nativas de esos lenguajes. En el lado del cliente, solo hay un lenguaje de programación que se ejecuta dentro de todos los navegadores web: JavaScript. El diccionario también es la estructura de datos fundamental dentro de JavaScript.

Por lo tanto, no es sorprendente que JSON, una sintaxis estructurada en diccionario y basada en JavaScript, se haya convertido en el estándar de facto para el intercambio de datos de aplicación a aplicación en la web en contextos que no involucran transacciones comerciales. Los servicios web que proporcionan datos estructurados destinados a uso programático pueden hacer que esos datos estén disponibles como JSON, que es muy adecuado para su uso ya sea por programas JavaScript que se ejecutan dentro de navegadores, o por programas escritos en otros idiomas que se ejecutan fuera de los navegadores (por ejemplo, aplicaciones de teléfonos inteligentes).

Ahora se acepta comúnmente que existen diferencias de enfoque útiles entre el mundo del procesamiento de documentos y el mundo web. Esto no quiere decir que los dos mundos no tengan superposiciones significativas. Algunos tipos de representación web muy importantes están basados en XML, como el formato de sindicación Atom. Los árboles seguirán siendo la estructura de elección para las representaciones web que consisten principalmente en datos narrativos más que transaccionales. Pero para descripciones estructuradas a las que se pretende acceder y manipular en la Web, actualmente gobiernan las estructuras de diccionario.

Para evaluar si las descripciones de sus recursos son o deberían formar parte del mundo Web, hágase las siguientes preguntas:

• ¿Es la web la plataforma principal sobre la que estaré poniendo a disposición mis descripciones?

• ¿Mis descripciones de recursos son principalmente datos estructurados y orientados a transacciones?

• ¿Mis descripciones pueden modelarse fácilmente como listas de propiedades y valores (diccionarios)?

• ¿Los vocabularios que necesito o quiero usar están disponibles principalmente usando tecnologías HTML como microdatos o microformatos?

• ¿Necesito hacer mis descripciones fácilmente utilizables para su uso dentro de una amplia gama de lenguajes de programación?

Si la respuesta a una o más de estas preguntas es “sí”, entonces es muy probable que estés trabajando dentro del Mundo Web, y tendrás que familiarizarte con conceptualizar tus descripciones como diccionarios y trabajar con ellas usando lenguajes de programación como JavaScript.

El Mundo de la Web Semántica

El último mundo que consideramos sigue siendo algo así como un mundo posible, al menos en comparación con los dos anteriores. Si bien el mundo del procesamiento de documentos y el mundo web están bien establecidos, el mundo de la Web Semántica apenas comienza a emerger, a pesar de haberse imaginado hace más de una década.

La visión de un mundo de la Web Semántica se basa en el mundo web, pero agrega algunas prescripciones y restricciones adicionales sobre cómo estructurar descripciones. El mundo de la Web Semántica unifica el concepto de recurso tal como se ha desarrollado en este libro, con la noción web de un recurso como cualquier cosa con un URI. En la Web Semántica, todo lo que se describa debe tener un URI. Además, las descripciones deben estar estructuradas como gráficas, apegándose al metamodelo RDF y relacionando recursos entre sí a través de sus URI s. Advocates of Linked Data prescriben además que esas descripciones deben estar disponibles como representaciones transferidas a través de HTTP . ^[4]

Esto es una desviación del mundo web. El mundo web también se estructura en torno a ^[5]

Hacer una solicitud HTTP a un URI de libro individual puede devolver una descripción estructurada en gráficos de ese libro, si se siguen las mejores prácticas para los Datos Enlazados. Esto, también, es una desviación del mundo web, que es agnóstico sobre la forma que deben tomar las representaciones o descripciones de los recursos (aunque como hemos visto, las estructuras de diccionario a menudo se ven favorecidas en la web cuando los clientes que consumen esas descripciones son programas de computadora). En la Web Semántica, todas las descripciones están estructuradas como gráficas RDF. Cada gráfico descriptivo enlaza con otras gráficas descriptivas haciendo referencia a estos recursos relacionados utilizando sus URI s. Así, al menos en teoría, todas las gráficas descriptivas de la Web Semántica están enlazadas en una sola estructura gráfica masiva. En la práctica, sin embargo, está lejos de estar claro que se trata de una meta alcanzable, o incluso deseable.

Si bien la Web Semántica está en su infancia, ya se ha puesto a disposición un número significativo de descripciones de recursos de acuerdo con los principios señalados anteriormente. Las descripciones publicadas de acuerdo con estos principios a menudo se denominan “Datos Enlazados. ” Ejemplos destacados incluyen: DBpedia, un gráfico de descripciones de temas de artículos de Wikipedia; el Archivo Virtual de Autoridad Internacional (VIAF), un gráfico de descripciones de nombres recopilados de los archivos de autoridad de nombres de diversas bibliotecas nacionales; GeoNames, un gráfico de descripciones de lugares; y Data.gov.uk, un gráfico de descripciones de datos públicos puestos a disposición por el gobierno del Reino Unido. ^[6]

A pesar de la creciente cantidad de Linked Data, las herramientas para trabajar con datos estructurados en gráficos siguen siendo inmaduras en comparación con la cadena de herramientas XML y los lenguajes de programación web. Aunque existe una sintaxis XML para RDF, usar la cadena de herramientas XML para trabajar con datos estructurados en gráficos es generalmente una mala idea. Y así como la mayoría de los lenguajes de programación no admiten trabajar de forma nativa con estructuras de árbol, la mayoría tampoco admite trabajar de forma nativa con estructuras gráficas. Almacenar y consultar datos estructurados en gráficos de manera eficiente requiere una base de datos gráfica o un almacén triple.

Aún así, el mundo de la Web Semántica tiene mucho que recomendarlo. Tener una forma común de identificar los recursos (el URI) y un único metamodelo compartido (RDF) para todas las descripciones de recursos hace que sea mucho más fácil combinar descripciones de diferentes fuentes. Para evaluar si las descripciones de sus recursos son o deberían formar parte del mundo de la Web Semántica, hágase las siguientes preguntas:

• ¿Es la web la plataforma principal sobre la que estaré poniendo a disposición mis descripciones?

• ¿Es importante que pueda agregar fácil y libremente los elementos de mis descripciones de diferentes maneras y combinarlos con descripciones creadas por otros?

• ¿Mis descripciones se modelan mejor como estructuras gráficas?

• ¿Los vocabularios que necesito o quiero usar han sido creados usando RDF?

• ¿Necesito trabajar con un cuerpo de descripciones existentes que hayan sido publicadas como Datos Enlazados?

Si la respuesta a una o más de estas preguntas es “sí”, entonces es muy probable que estés trabajando dentro del mundo de la Web Semántica, y deberías familiarizarte con conceptualizar tus descripciones como gráficas y trabajar con ellas usando herramientas de la Web Semántica.

---

1. Cabe señalar que el contenido del Infoset para un documento determinado puede verse afectado por el conocimiento de cualquier Inclusión y Referencias relacionadas.)

   
   

2. Los microdatos son una invención de WHATWG y existe y forma parte de lo que ellos llaman un “nivel de vida”. ” Fue apoyado por Google, por lo que fue ampliamente utilizado y existen numerosos vocabularios controlados, entre ellos los de obras creativas, personas, eventos y organizaciones. Desde entonces, se ha retirado el soporte para microdatos de los navegadores Apple Safari y Google Chrome.

   
   

3. Microformatos es un no-estándar que surgió de la comunidad y ha sido patrocinado por CommerceNet y Microformats.org.

   
   

4. (Bizer, Heath y Berners-Lee 2009).

   
   

5. Vale la pena señalar que los URI no están obligados a tener nada en sus puntos finales. La resolubilidad de URI es evangelizada como una mejor práctica para Linked Data pero no como un requisito dentro del paradigma más amplio de la Web Semántica. Basta con afirmar que un URI está asociado a un libro. Si el URI puede devolver una descripción o un recurso, tanto mejor, pero si no, al menos se puede hablar del libro haciendo referencia al mismo URI.

   
   

6. Muchos más conjuntos de datos disponibles se enumeran en linkedreferences.