9.2: Descripciones de estructuración

Elegir cómo estructurar las descripciones de los recursos es una cuestión de tomar decisiones de diseño con principios y propósito para resolver problemas específicos, servir a propósitos específicos o lograr alguna propiedad deseable en las descripciones. La mayoría de estas decisiones son específicas de un dominio: el contexto particular de aplicación para el sistema de organización que se está diseñando y los tipos de interacciones con los recursos que permitirá. La toma de este tipo de decisiones específicas de contexto da como resultado un modelo de ese dominio. (Ver “Abstracción en Descripción del Recurso”.)

Con el tiempo, muchas personas han construido tipos similares de descripciones. Han tenido propósitos similares, han deseado propiedades similares y han enfrentado problemas similares. Como era de esperar, han convergido en algunas de las mismas decisiones. Cuando se pueden identificar conjuntos comunes de decisiones de diseño que no son específicos de ningún dominio, a menudo se sistematizan en los libros de texto y en las prácticas de diseño, y eventualmente pueden diseñarse en formatos y arquitecturas estándar para crear sistemas de organización. Estos conjuntos formalmente reconocidos de decisiones de diseño se conocen como modelos abstractos o metamodelos. Los metamodeles describen estructuras que se encuentran comúnmente en descripciones de recursos y otros recursos de información, independientemente del dominio específico. Si bien cualquier diseñadora de un sistema de organización suele crear un modelo de su dominio específico, por lo general no creará un metamodelo completamente nuevo sino que tomará decisiones entre los metamodelos que han sido formalmente reconocidos e incorporados a los estándares existentes. El modelo resultante a veces se llama un “lenguaje específico de dominio. ” La reutilización de metamodelos estándar puede traer grandes ventajas económicas, ya que los desarrolladores pueden reutilizar herramientas diseñadas y conocimiento sobre estos metamodelos, en lugar de tener que comenzar de cero.

En las siguientes secciones, examinamos algunos tipos comunes de estructuras utilizadas como base para los metamodeles. Pero primero, consideramos un ejemplo concreto de cómo la estructura de las descripciones de recursos soporta o inhibe usos particulares. Como explicamos en Fundamentos para los Sistemas Organizadores, el concepto de un recurso desenfatiza las diferencias entre las cosas físicas y digitales a favor de enfocarse en cómo se utilizan las cosas, en general, para apoyar la actividad orientada a objetivos. Diferentes tipos de libros pueden ser tratados como recursos de información independientemente de la mezcla particular de propiedades tangibles e intangibles que puedan tener. Dado que las descripciones de recursos también son recursos de información, podemos considerar de manera similar cómo sus estructuras soportan usos particulares, independientemente de si son físicos, digitales o una mezcla de ambos.

Una tarjeta de listón

Un ejemplo de una tarjeta perforadora utilizada por Batten para describir una patente particular en una colección de patentes. Cada carta representaba un término descriptivo individual, y cada posición de puñetazo en una tarjeta representaba una patente particular.

Durante la Segunda Guerra Mundial, un químico británico llamado W. E. Batten desarrolló un sistema para organizar patentes. ^[1] El sistema consistió en un lenguaje para describir el producto, proceso, uso y aparato de una patente, y una forma de usar tarjetas perforadas para registrar estas descripciones. Batten utilizó tarjetas impresas con matrices de 800 posiciones (ver Figura: Una Carta de Listón.). Cada tarjeta representaba un valor específico del vocabulario del lenguaje descriptivo, y cada posición correspondía a una patente particular. Para describir la patente ^# 256 como extrusión de recubrimiento de polietileno para producir cubiertas de cables, primero se seleccionarían las tarjetas para los valores de polietileno, extrusión y revestimientos de cables, y luego perfora cada tarjeta en la ^posición 256. La descripción de la patente ^# 256 se extendería así sobre estas tres tarjetas.

La ventaja de esta estructura es que para encontrar patentes que cubran la extrusión de polietileno (para cualquier propósito), uno solo necesita seleccionar las dos tarjetas correspondientes a esos valores, colocar una encima de la otra y sujetarlas a una luz. La luz brillará por donde haya una posición correspondiente a una patente descrita usando esos valores. Las patentes que cumplen una determinada descripción se encuentran fácilmente debido a la estructura de las tarjetas diseñadas para describir las patentes.

Máquina de Punchcard

Las tarjetas perforadoras fueron un importante medio de entrada y almacenamiento de información durante décadas, incluso antes de la invención de las computadoras. El punzón de teclado Hollerith se utilizó para transcribir la información recopilada en el censo de Estados Unidos de 1890. La plantilla que se utiliza en esta foto es para registrar información sobre una granja. Las tarjetas perforadas fueron tabuladas por máquinas electromecánicas. Una fusión de cuatro compañías de máquinas tabuladoras en 1911 creó una compañía cuyo nombre actual es IBM.

Esta máquina perforadora de teclado se encuentra en la colección del Museo de Historia de la Computación en Mountain View, California.

(Foto de R. Glushko.)

Por supuesto, este sistema también tiene claras desventajas. Encontrar los conceptos asociados a una patente en particular es tedioso, porque cada tarjeta debe ser inspeccionada. Agregar una nueva patente es relativamente fácil siempre y cuando haya un índice que permita ubicar rápidamente las tarjetas para conceptos específicos. Sin embargo, una vez que las tarjetas se quedan sin espacio para perforar agujeros, todo el juego de tarjetas debe duplicarse para dar cabida a más patentes: una operación muy costosa. Agregar nuevos conceptos es potencialmente fácil: simplemente agregue una nueva tarjeta. Pero si queremos poder encontrar patentes existentes utilizando el nuevo concepto, todas las patentes existentes tendrían que ser reexaminadas para determinar si sus posiciones sobre la nueva tarjeta deberían ser perforadas: también una operación costosa.

La estructura de las tarjetas de Batten soportaba una rápida selección de recursos dada una descripción parcial. Los tipos de estructuras que examinaremos en las siguientes secciones no son tan elaborados como las cartas de Batten. Pero al igual que las tarjetas, cada tipo de estructura soporta una ejecución mecánica más eficiente de ciertas operaciones, a costa de una ejecución menos eficiente de otras.

Tipos de Estructuras

Los conjuntos, listas, diccionarios, árboles y gráficos son tipos de estructuras que se pueden usar para formar descripciones de recursos. Como veremos, cada uno de estos tipos es en realidad una familia de estructuras relacionadas. Estas estructuras son abstracciones: describen las propiedades estructurales formales de manera general, en lugar de especificar una forma física o textual exacta. Las abstracciones son útiles porque nos ayudan a ver propiedades comunes compartidas por diferentes formas específicas de organizar la información. Al enfocarnos en estas propiedades comunes, podemos razonar más fácilmente sobre las operaciones que soportan las diferentes formas y las posibilidades que brindan, sin distraernos por detalles menos relevantes.

Blobs

El tipo de estructura más simple no es ninguna estructura en absoluto. Considere la siguiente descripción de un libro: La novela de Sebald utiliza un recorrido a pie por East Anglia para meditar sobre los vínculos entre pasado y presente, Oriente y Occidente. ^[2] Esta descripción es una expresión de texto no estructurado sin partes internas claramente definidas, y podemos considerarla como un blob. O, más precisamente, tiene estructura, pero esa estructura es la estructura gramatical subyacente del idioma inglés, y ninguna de esa estructura gramatical se representa explícitamente en una estructura superficial cuando se expresa la oración. Como lectores del inglés podemos interpretar la oración como una descripción del tema del libro, pero hacerlo mecánicamente es difícil. ^[3] Por otro lado, tal descripción escrita es relativamente fácil de crear, ya que el descriptor puede simplemente usar el lenguaje natural.

Un blob no necesita ser un blob de texto. Podría ser una fotografía de un recurso, o una grabación de una descripción hablada de un recurso. Al igual que los blobs de texto, los blobs de píxeles o el sonido tienen una estructura subyacente que cualquier persona con visión o audición normales puede entender fácilmente. ^[4] Pero podemos tratar estas manchas como desestructuradas, porque ninguna de las estructuras subyacentes en la entrada visual o auditiva es explícita, y nos preocupan las formas en que las estructuras de las descripciones de recursos apoyan o inhiben las operaciones mecánicas o computacionales. ^[5]

Sets

La forma más sencilla de estructurar una descripción es darle partes y tratarlas como un conjunto. Por ejemplo, la descripción de la novela de Sebald podría reformularse como un conjunto de términos: Sebald, novela, East Anglia, caminar, historia. Hacer esto ha perdido gran parte del significado, pero se ha ganado algo: ahora podemos distinguir fácilmente a Sebald y caminar como elementos separados en la descripción. ^[6] Esto facilita encontrar, por ejemplo, todas las descripciones que incluyen el término caminar. (Tenga en cuenta que esto es diferente de simplemente buscar a través de descripciones de blob-of-text para la palabra caminar. Cuando se trata como un conjunto, la descripción Fiji, fuego caminando, memorias no incluye el término caminar, aunque sí incluye el término caminar fuego.)

Los sets facilitan la búsqueda de intersecciones entre descripciones. Los sets también son fáciles de crear. En “Clasificación vs. etiquetado” observamos “folksonomías”, sistemas de organización en los que los usuarios no profesionales crean descripciones de recursos. En estos sistemas, las descripciones se estructuran como conjuntos de “etiquetas”. ” Para encontrar recursos, los usuarios pueden especificar un conjunto de etiquetas para obtener recursos que tengan descripciones que se crucen en esas etiquetas. Esto es más valioso si las etiquetas provienen de un vocabulario controlado, haciendo que las intersecciones sean más probables. Pero hacer cumplir el control del vocabulario agrega complejidad al proceso de descripción, por lo que se debe lograr un equilibrio entre maximizar las intersecciones potenciales y hacer que la descripción sea tan simple como práctica. ^[7]

Un conjunto es un tipo o clase de estructura. Podemos refinar la definición de diferentes tipos de conjuntos mediante la introducción de restricciones. Por ejemplo, podríamos introducir la restricción de que un conjunto dado tiene un número máximo de elementos. O podríamos constreñir un conjunto para que siempre tenga el mismo número de artículos, dándonos un conjunto de tamaño fijo. También podemos eliminar restricciones. Los conjuntos no contienen elementos duplicados (piense en un sistema de etiquetado en el que no tenga sentido asignar la misma etiqueta más de una vez al mismo recurso). Si eliminamos esta restricción de singularidad, tenemos una estructura diferente conocida como “bolsa” o “multiset. ”

Listas

Las restricciones son las que distinguen las listas de los conjuntos. Una lista, como un conjunto, es una colección de elementos con una restricción adicional: sus artículos están ordenados. Si estuviéramos diseñando un sistema de etiquetado en el que fuera importante que se mantuviera el orden de las etiquetas, querríamos usar listas, no conjuntos. A diferencia de los conjuntos, las listas pueden contener elementos duplicados. En una lista, dos elementos que de otra manera son iguales se pueden distinguir por su posición en el orden, pero en un conjunto esto no es posible. Por ejemplo, podríamos querer organizar las etiquetas asignadas a un recurso, enumerando primero la etiqueta más utilizada, la última con menos frecuencia y el resto según su frecuencia de uso.

Nuevamente, podemos introducir restricciones para refinar la definición de diferentes tipos de listas, como las listas de longitud fija. Si limitamos una lista para que contenga solo elementos que son en sí mismas listas, y especificamos además que estas listas contenidas no contienen listas, entonces tenemos una tabla (una lista de listas de elementos). Una hoja de cálculo es una lista de listas.

Diccionarios

Una limitación importante de las listas y conjuntos es que, aunque los ítems pueden ser abordados individualmente, no hay manera de distinguir los ítems excepto comparando sus valores (o, en una lista, sus posiciones en el orden). En un conjunto de términos como Sebald, novela, East Anglia, caminar, historia, por ejemplo, no se puede decir fácilmente que Sebald se refiere al autor del libro mientras que East Anglia y caminar se refieren a lo que es acerca de. Una forma de abordar este problema es dividir cada elemento de un conjunto en dos partes: una propiedad y un valor. Entonces, por ejemplo, nuestro sencillo conjunto de etiquetas podría convertirse en autor: Sebald, type: novel, subject: East Anglia, subject: walking, subject: history. Ahora podemos decir que autor, tipo y sujeto son las propiedades, y los elementos originales en el conjunto son los valores.

autor

Sebald

tipo

novela

tema1

Anglia Oriental

tema2

caminando

tema3

historia

Este tipo de estructura se llama diccionario, mapa o matriz asociativa. Un diccionario es un conjunto de pares o entradas propiedad-valor. Se trata de un conjunto de entradas, no una lista de entradas, porque los pares no están ordenados y porque cada entrada debe tener una clave única. ^[8] Obsérvese que este significado especializado de diccionario es diferente del significado más común de “diccionario” como una lista alfabetizada de términos acompañada de oraciones que los definen. Los dos significados están relacionados, sin embargo. Al igual que un diccionario “real”, una estructura de diccionario nos permite encontrar fácilmente el valor (como una definición) asociado a una propiedad o clave particular (como una palabra). Pero a diferencia de un diccionario real, que ordena sus claves alfabéticamente, una estructura de diccionario no especifica un orden para sus claves. ^[9]

Los diccionarios son ubicuos en las descripciones de recursos. Las descripciones estructuradas ingresadas mediante un formulario se representan fácilmente como diccionarios, donde las etiquetas de los elementos del formulario son las propiedades y los datos ingresados son los valores. Los datos tabulares con una “fila de encabezado” se pueden considerar como un conjunto de diccionarios, donde los encabezados de columna son las propiedades de cada diccionario, y cada fila es un conjunto de valores correspondientes. Los diccionarios también son un tipo básico de estructura de datos que se encuentra en casi todos los lenguajes de programación (denominados matrices asociativas).

Nuevamente, podemos introducir o eliminar restricciones para definir tipos especializados de diccionarios. Un diccionario ordenado agrega un orden sobre las entradas; en otras palabras, es una lista de entradas en lugar de un conjunto. Un multimapa es un diccionario en el que múltiples entradas pueden tener la misma clave.

Árboles

En los diccionarios como se entienden comúnmente, las propiedades son términos y los valores son sus definiciones correspondientes. Los términos y valores suelen ser palabras, frases u otras expresiones que se pueden ordenar alfabéticamente. Pero si generalizar la noción de un diccionario como conjuntos abstractos de pares propiedad-valor, los valores pueden ser cualquier cosa en absoluto. En particular, los valores pueden ser en sí mismos diccionarios. Cuando una estructura de diccionario tiene valores que son en sí mismos diccionarios, decimos que los diccionarios están anidados. El anidamiento es muy útil para descripciones de recursos que necesitan más estructura de la que puede proporcionar un diccionario (no anidado).

Figura: Cuatro diccionarios anidados. presenta un ejemplo de diccionarios anidados. En el nivel superior hay un diccionario con una sola entrada que tiene la propiedad a. El valor asociado con a es un diccionario que consta de dos entradas, la primera teniendo la propiedad b y la segunda teniendo la propiedad c. Los valores asociados con b y con c también son diccionarios.

Cuatro diccionarios anidados

Si anidamos diccionarios así, y nuestro diccionario “top” (el que contiene todos los demás) solo tiene una entrada, entonces tenemos una especie de estructura de árbol. Figura: Un árbol de propiedades y valores. muestra las mismas propiedades y valores que la Figura: Cuatro Diccionarios Anidados., esta vez dispuestos para hacer más visible la estructura de árbol. Los árboles constan de nodos (las letras y números de la Figura: Un Árbol de Propiedades y Valores.) unidos por aristas (las flechas). Cada nodo en el árbol con un círculo alrededor de él es una propiedad, y el valor de cada propiedad consiste en los nodos debajo (a la derecha de) en el árbol. Un nodo es referido como el padre de los nodos debajo de él, que a su vez son referidos como los hijos de ese nodo. Los bordes muestran estas relaciones “padre de” entre los nodos. El nodo sin padre se llama la raíz del árbol. Los nodos sin hijos se denominan nodos foliares.

Un árbol de propiedades y valores

Una representación alternativa de diccionarios anidados es como un árbol. El nivel más bajo o los nodos de hoja del árbol contienen valores de propiedad.

Al igual que con los otros tipos de estructuras que hemos considerado, podemos definir diferentes tipos de árboles introduciendo diferentes tipos de restricciones. Por ejemplo, el metamodelo predominante para XML Information Set o Infoset. ^[10]

El conjunto de información XML define un tipo específico de estructura de árbol agregando restricciones muy específicas, incluido el orden de los nodos secundarios, a la definición básica de un árbol. La adición de una restricción de orden distingue Figura: Un árbol de propiedades y valores. representa un tipo de árbol con un conjunto diferente de restricciones: todos los nodos que no son hojas son propiedades y todas las hojas son valores. También podríamos definir un árbol en el que cada nodo tenga tanto una propiedad como un valor. Los árboles existen en una gran variedad de sabores, pero todos comparten una topología común: los bordes entre los nodos están dirigidos (un nodo es el padre y el otro es el hijo), y cada nodo excepto la raíz tiene exactamente un padre.

Los árboles proporcionan una forma de agrupar declaraciones que describen recursos diferentes pero relacionados. Por ejemplo, considere la descripción estructurada como un diccionario aquí:

Descripción Estructurado como un Diccionario

nombres dados del autor → Winfried Georg apellido
del autor → Sebald
title → Die Ringe des Saturn
páginas → 371

El diccionario agrupa cuatro pares propiedad-valor que describen un libro en particular. (Las flechas son simplemente una forma esquemática de indicar las relaciones propiedad-valor. Más adelante en el capítulo nos fijamos en formas de “escribir” estas relaciones usando alguna sintaxis específica.)

Pero realmente las dos primeras entradas no están describiendo el libro; están describiendo al autor del libro. Entonces, sería mejor agrupar esas dos declaraciones de alguna manera. Podemos hacer esto anidando las entradas que describen al autor dentro de la descripción del libro, creando una estructura de árbol:

Anidar una descripción de autor dentro de un libro Descripción

autor → nombres de
pila → Winfried Georg
apellido →
Título sebald → Die Ringe des Saturn
páginas → 371

El uso de un árbol funciona bien en este caso porque podemos tratar al libro como el recurso principal que se describe, convirtiéndolo en la raíz de nuestro árbol, y agregando la descripción del autor como una “rama. ”

También podríamos haber optado por hacer del autor el recurso principal, dándonos un árbol como el de Ejemplo: Anidar descripciones de libros dentro de una descripción de autor.

Anidar descripciones de libros dentro de una descripción de autor

nombres de pila → Winfried Georg
apellido → Sebald
libros de autor →
1. título → Die Ringe des Saturn
páginas → 371
2. título → Austerlitz
páginas → 416

Tenga en cuenta que en este diccionario, el valor de la propiedad de libros de autor es una lista de diccionarios. Hacer del autor el recurso principal o raíz nos permite incluir múltiples descripciones de libros en el árbol (pero hace que sea más difícil describir libros que tengan múltiples autores). Un árbol es una buena opción para estructurar descripciones siempre y cuando podamos identificar claramente un recurso primario. En algunos casos, sin embargo, queremos conectar descripciones de recursos relacionados sin tener que designar uno como primario. En estos casos, necesitamos una estructura de datos más flexible.

Gráficas

Supongamos que estábamos describiendo dos libros, donde el autor de un libro es el tema del otro, como en Ejemplo: Dos descripciones relacionadas:

Dos descripciones relacionadas

1. autor → Mark Richard McCulloch
title → Entendiendo W. G. Sebald
tema → Winfried Georg Sebald
2. autor → Winfried Georg Sebald
title → Die Ringe des Saturn

Al observar estas descripciones, podemos adivinar la relación entre los dos libros, pero esa relación no se representa explícitamente en la estructura: solo tenemos dos diccionarios separados y hemos inferido la relación haciendo coincidir los valores de las propiedades. Es posible que esta inferencia pueda estar equivocada: podría haber dos personas llamadas Winfried Georg Sebald. ¿Cómo podemos estructurar estas descripciones para representar explícitamente el hecho de que el Winfried Georg Sebald que es el tema del primer libro es el mismo Winfried Georg Sebald que escribió el segundo?

Una posibilidad sería hacer de Winfried Georg Sebald la raíz de un árbol, similar al enfoque adoptado en Ejemplo: Anidar descripciones de libros dentro de una descripción de autor, agregar un libro sobre propiedad junto a los libros de autor uno. Esta solución funcionaría bien si las personas fueran nuestros recursos principales y, por lo tanto, tenía sentido estructurar nuestras descripciones en torno a ellos. Pero supongamos que habíamos decidido que nuestras descripciones debían estructurarse en torno a los libros, y que estábamos usando un vocabulario que tomara esta perspectiva (con propiedades como autor y tema en lugar de libros de autor y libros sobre). No debemos dejar que una estructura en particular limite la perspectiva organizacional que podemos tomar, como lo hicieron las tarjetas de Batten. En cambio, debemos elegir conscientemente estructuras que se adapten a nuestra perspectiva organizacional. ¿Cómo podemos hacer esto?

Si tratamos nuestras dos descripciones de libros como árboles, podemos unir las dos ramas (sujeto y autor) que comparten un valor. Cuando hacemos esto, ya no tenemos un árbol, porque ahora tenemos un nodo con más de un padre (Figura: Descripciones Vinculadas en una Gráfica.) . La estructura en la Figura: Descripciones Vinculadas en un Gráfico. es una gráfica. Al igual que un árbol, una gráfica consiste en un conjunto de nodos conectados por bordes. Estos bordes pueden tener o no una dirección (“Direccionalidad”). Si lo hacen, la gráfica es referida como una “gráfica dirigida. ” Si se dirige una gráfica, puede ser posible comenzar en un nodo y seguir bordes en una ruta que conduzca de regreso al nodo inicial. Tal camino se llama un “ciclo. ” Si una gráfica dirigida no tiene ciclos, se le conoce como “gráfica acíclica. ”

Un árbol es solo un tipo de gráfico más restringido. Los árboles son gráficos dirigidos porque la relación “padre de” entre los nodos es asimétrica: los bordes son flechas que apuntan en cierta dirección. (Ver “Simetría”.) Además, los árboles son gráficos acíclicos, porque si sigues los bordes dirigidos de un nodo a otro, nunca podrás encontrar el mismo nodo dos veces. Finalmente, los árboles tienen la restricción de que cada nodo (excepto la raíz) debe tener exactamente un padre. ^[11]

En Figura: Descripciones Vinculadas a un Gráfico. hemos violado esta restricción al unir nuestros dos árboles de libros. La gráfica que resulta sigue siendo dirigida y acíclica, pero debido a que el nodo Winfried George Sebald ahora tiene dos padres, ya no es un árbol.

Detener y pensar: Propiedades de redes sociales

Comparar el concepto de “amigo” en Facebook con el de “seguidor” en Twitter, en términos de las propiedades semánticas discutidas en “Propiedades de las relaciones semánticas” y las propiedades gráficas discutidas en esta sección.

Las gráficas son estructuras muy generales y flexibles. Muchos tipos de sistemas pueden concebirse como nodos conectados por bordes: estaciones conectadas por líneas de metro, personas conectadas por amistades, decisiones conectadas por dependencias, etc. Las relaciones se pueden modelar de diferentes maneras usando diferentes tipos de grafos s. Por ejemplo, si asumimos que la amistad es simétrica (ver “Simetría”), usaríamos una gráfica no dirigida para modelar la relación. No obstante, en las redes sociales basadas en la web la amistad suele ser asimétrica (podrías “amigo” de alguien que no corresponda), por lo que una gráfica dirigida es más apropiada.

Descripciones vinculadas a una gráfica

Las descripciones se pueden vincular para formar una gráfica cuando el valor asignado a dos propiedades diferentes es el mismo.

A menudo es útil tratar una gráfica como un conjunto de pares de nodos, donde cada par puede o no estar conectado directamente por un borde. Muchos enfoques para caracterizar las relaciones estructurales entre recursos (ver “Relaciones estructurales entre recursos”) se basan en modelar los recursos relacionados como un conjunto de pares de nodos, y luego analizar patrones de conectividad entre ellos. Como veremos, poder descomponer una gráfica en pares también es útil cuando estructuramos descripciones de recursos como gráficas s.

En “El mundo del procesamiento de documentos” utilizaremos Figura: Descripciones Vinculadas en un Gráfico. mediante el uso de “referencias” para conectar un libro a su título, autores y tema. Esto nos permitirá desarrollar sofisticadas gráficas de conocimiento dentro de una única instancia de documento XML. (Ver también la barra lateral, Inclusiones y Referencias) ^[12]

Comparación de Metamodeles: JSON, XML y RDF

Ahora que estamos familiarizados con los diversos tipos de metamodeles utilizados para estructurar descripciones de recursos, podemos echar un vistazo más de cerca a algunos metamodeles específicos. Una comparación detallada de las posibilidades de los diferentes metamodeles está fuera del alcance de este capítulo. Aquí simplemente echaremos un breve vistazo a tres metamodelos populares —JSON, XML y RDF — para ver cómo especifican y limitan aún más los tipos más generales de metamodelos introducidos anteriormente.

JSON

Notación de objetos JavaScript (JSON)

JavaScript Object Notation (JSON) es un formato textual para intercambiar datos que toma prestado su metamodelo del lenguaje de programación JavaScript. Específicamente, el metamodelo JSON consiste en dos tipos de estructuras que se encuentran en JavaScript: listas (llamadas “arrays” en JavaScript) y diccionarios (llamados “objetos” en JavaScript). Las listas y diccionarios contienen valores, que pueden ser cadenas de texto, números, booleanos (verdadero o falso) o el valor nulo (vacío). Nuevamente, este tipo de valores se toman directamente de JavaScript. Las listas y diccionarios también pueden ser valores, las listas de significado y los diccionarios se pueden anidar entre sí para producir estructuras más complejas como tablas y árboles.

Listas, diccionarios y un conjunto básico de tipos de valores constituyen los “Sistemas de Escritura” más adelante en este capítulo.) Además, muchos lenguajes de programación modernos proporcionan estructuras de datos y tipos de valor equivalentes a los proporcionados por JavaScript. Entonces, los datos representados como JSON son fáciles de trabajar en muchos lenguajes de programación, no solo JavaScript.

Conjunto de información XML

El metamodelo del Conjunto de Información XML se deriva de las estructuras de datos utilizadas para el marcado de documentos. (Ver “Metadatos”.) Estas estructuras de marcado —elementos y atributos — son adecuadas para manipular programáticamente la estructura de documentos y datos juntos. ^[13]

Infoset XML

El Infoset XML es una estructura de árbol, donde cada nodo del árbol se define como un “elemento de información” de un tipo particular. Cada elemento de información tiene un conjunto de propiedades específicas de tipo asociadas a él. En la raíz del árbol hay un “elemento de documento”, que tiene exactamente un “elemento elemento” como hijo. Un elemento de elemento tiene un conjunto de elementos de atributo y una lista de nodos secundarios. Estos nodos hijos pueden incluir otros elementos de elementos, o pueden ser elementos de carácter. (Consulte “Tipos de estructuras” a continuación para obtener más información sobre los personajes.) Los elementos de atributo pueden contener elementos de carácter, o pueden contener datos mecanografiados, como fichas de nombre, identificadores y referencias. Los identificadores y referencias de elementos (ID/IDREF) se pueden utilizar para conectar nodos, transformando un árbol en una gráfica. (Ver la barra lateral, Inclusiones y Referencias.) ^[14]

Figura: Una Estructura Descripción. es una representación gráfica de cómo un documento XML podría ser utilizado para estructurar parte de una descripción de un autor y sus obras. Este ejemplo demuestra cómo podríamos usar elementos de elemento para modelar el dominio de la descripción, dándoles nombres como autor y título. Los elementos de carácter que son hijos de estos elementos contienen el contenido de la descripción: nombres de autores, títulos de libros, etc. Los elementos de atributo se utilizan para contener información auxiliar sobre este contenido, como su idioma.

Una estructura de descripción

Un documento XML se puede describir como un árbol en el que los elementos son nodos que pueden contener contenido de caracteres directamente o atributos que contienen contenido de caracteres.

Este ejemplo también demuestra cómo el Infoset XML admite contenido mixto al permitir que los elementos de elementos y elementos de carácter sean “hermanos” del mismo elemento padre. En este caso, la estructura Infoset nos permite especificar que la descripción del libro puede mostrarse como una línea de texto que consiste en el título original y el título traducido entre paréntesis. Los elementos y atributos se utilizan para indicar que esta línea de texto consta de dos títulos escritos en diferentes idiomas, no un solo título que contiene paréntesis.

Si no fuera por contenido mixto, no podríamos escribir texto narrativo con enlaces de hipertexto incrustados en medio de una oración. Nos da la capacidad de identificar los subcomponentes de una oración, para que podamos distinguir los términos “Sebald”, “caminando” y “East Anglia” como autor y dos sujetos.

Inclusiones y Referencias

Un ^[15] Esquemas asociados a ^[16] Tradicionalmente, cualquier documentación que esté relacionada con el esquema se considera parte de la definición del esquema y, al menos teóricamente, informa la comprensión humana y la interpretación de los documentos correspondientes. ^[17]

La familia XML ofrece varios mecanismos para crear relaciones de inclusión: empleando referencias de elementos; a modo de definición de entidad y referencia; mediante el uso de Inclusiones XML (XInclude) o XLink. Estas inclusiones y referencias también pueden informar al Infoset XML, si se procesan.

Cualquiera ^[18]

xInclude “especifica un modelo de procesamiento y sintaxis para la inclusión de propósito general. La inclusión se logra fusionando una serie de conjuntos de información XML en un solo conjunto de infoset compuesto. ” XInclude ofrece el mecanismo más versátil para abordar documentos completos, elementos de información específicos, rangos de elementos de información e incluso partes de elementos de información, lo que ha llevado a su adopción generalizada en el procesamiento de documentos. ^[19]

XLink “permite insertar elementos en documentos XML para crear y describir vínculos entre recursos. Utiliza la sintaxis XML para crear estructuras que puedan describir enlaces similares a los simples hipervínculos unidireccionales del HTML actual, así como enlaces más sofisticados. ” ^[20]

Las entidades son similares a las macros que se encuentran en muchos lenguajes de programación; se asigna un valor a un token, se hace referencia al token donde sea necesario y la expansión de macros ocurre cuando la instancia del documento XML se lee en el Infoset. ^[21] Las entidades son una característica útil, pero como se expanden en su camino, las entidades no sobreviven como elementos de información en el Infoset XML. La función ID/IDREF es más popular que el uso de entidades porque lleva más información al Infoset XML.

El uso de esquemas para definir formatos de representación de datos es una buena práctica que facilita la comprensión compartida y contribuye a la mantenibilidad a largo plazo en contextos institucionales o empresariales. Un esquema XML representa un contrato entre las partes suscritas a sus definiciones, mientras que JSON depende de la comunicación fuera de banda entre los programadores. La noción de que “el código es la documentación” puede estar de moda entre los programadores, pero los modeladores prefieren diseñar a un nivel superior de abstracción y luego implementarlo.

El Infoset XML presenta un fuerte contraste con JSON y no siempre mapea de manera sencilla a las estructuras de datos utilizadas en los lenguajes populares de scripting web. Mientras que las estructuras de JSON facilitan que los programadores orientados a objetos intercambien datos fácilmente, carecen de cualquier lenguaje de esquema formal y no pueden manejar fácilmente contenido mixto.

RDF

En Figura: Descripciones Vinculadas en una Gráfica., estructuramos nuestra descripción de recursos como una gráfica tratando recursos, propiedades y valores como nodos, con bordes reflejando su combinación en declaraciones descriptivas. Sin embargo, un enfoque más común es tratar los recursos y valores como nodos, y las propiedades como los bordes que los conectan. Figura: Tratamiento de las propiedades como bordes en lugar de nodos. muestra la misma descripción que la Figura: Descripciones Vinculadas en una Gráfica., esta vez con propiedades tratadas como bordes. Esto corresponde aproximadamente al tipo particular de metamodelo gráfico definido por RDF. (“Marco de descripción de recursos (RDF)”)

Tratamiento de las propiedades como bordes en lugar de nodos

Podemos tratar cada componente de una descripción como un par de nodos (un recurso y un valor) con un borde (la propiedad) vinculándolos. Aquí, tenemos dos recursos de libro que están relacionados con cuatro valores a través de cinco propiedades. El nodo de valor único, “Winfried George Sebald” es el tema de un libro a la vez que es el autor del segundo libro. Los libros se representan como cajas, los bordes como flechas etiquetadas y los valores como cadenas de texto.

Hemos señalado que podemos tratar una gráfica como un conjunto de pares de nodos, donde cada par puede estar conectado por un borde. De igual manera, podemos tratar cada componente de la descripción en la Figura: Tratamiento de las propiedades como bordes en lugar de nodos. como un par de nodos (un recurso y un valor) con un borde (la propiedad) vinculándolos. En el metamodelo RDF, un par de nodos y su borde se llama triple, porque consta de tres partes (dos nodos y un borde). El metamodelo RDF es una gráfica dirigida, por lo que identifica a un nodo (aquel desde el que apunta el borde) como sujeto del triple, y al otro nodo (aquel al que apunta el borde) como su objeto. El borde se conoce como el predicado o (como venimos diciendo) propiedad del triple.

Listado se triplica individualmente

Enumera cada uno de los triples individualmente. Aquí, cada declaración relaciona un recurso con un valor a través de un borde. Así, tenemos dos nodos de valor distintos “Winfried George Sebald”. Los libros se representan como cajas, los bordes como flechas etiquetadas y los valores como cadenas de texto.

Figura: Listado de Triples Individualmente. enumera por separado todos los triples en la Figura: Tratamiento de las propiedades como bordes en lugar de nodos. Sin embargo, hay algo que falta en la Figura: Listado Triples Individualmente.. Figura: Tratar las propiedades como bordes en lugar de nodos. indica claramente que el Winfried George Sebald que es el tema del libro 1 es el mismo Winfried George Sebald que es el autor del libro 2. En la Figura: Listado Triples Individualmente. esta relación no está clara. ¿Cómo podemos saber si el Winfried George Sebald del tercer triple es lo mismo que el Winfried George Sebald de la triple declaración? Para el caso, ¿cómo podemos saber si las tres primeras triples involucran todas el mismo libro 1? Esto es fácil de mostrar en un diagrama de toda la gráfica de descripción, donde podemos tener múltiples bordes unidos a un nodo. Pero cuando desagregamos esa gráfica en triples, necesitamos alguna forma de referirnos de manera única a los nodos. Necesitamos identificadores (“Elegir buenos nombres e identificadores”). Cuando dos triples tienen nodos con el mismo identificador, podemos saber que es el mismo nodo. RDF logra esto asociando URI con nodos. (Ver “Marco de Descripción de Recursos (RDF)”)

La necesidad de identificar nodos cuando dividimos una gráfica RDF en triples se vuelve importante cuando queremos “escribir” gráficas RDF —crear representaciones textuales de ellas en lugar de representarlas — para que puedan intercambiarse como datos. Las estructuras de árbol no necesariamente tienen este problema, porque es posible representar textualmente una estructura de árbol sin tener que mencionar ningún nodo más de una vez. Así, un precio pagado por la generalidad y flexibilidad de las estructuras gráficas es la complejidad añadida de registrar, representar o escribir esas estructuras.

Elegir sus restricciones

Esta compensación entre flexibilidad y complejidad ilustra un punto más general sobre las restricciones. En el contexto de gestionar e interactuar con descripciones de recursos, las restricciones son algo bueno. Como se discutió anteriormente, un árbol es una gráfica con restricciones muy específicas. Estas restricciones permiten hacer cosas con árboles que no son posibles con gráficos en general, como representarlos textualmente sin repetirse, o identificar de manera única nodos por el camino desde la raíz del árbol hasta ese nodo. Esto puede hacer que la gestión de las descripciones y los recursos que describen sea más fácil y eficiente, si una estructura de árbol se ajusta bien a los requisitos del sistema de organización. Por ejemplo, una estructura de árbol ordenada es una buena opción para la estructura jerárquica del contenido de un libro o documento similar a un libro, como un manual de servicio de una aeronave o una presentación SEC. Por otro lado, la red de relaciones entre las personas y organizaciones que colaboraron para producir un libro podría estar mejor representada utilizando una estructura gráfica. XML se usa con mayor frecuencia para representar jerarquías, pero también es capaz de representar estructuras de red.

Modelado dentro de restricciones

Un metamodelo impone ciertas limitaciones a la estructura de nuestras descripciones de recursos. Pero en los sistemas de organización, generalmente necesitamos especificar más el contenido y la composición de las descripciones de los tipos específicos de recursos que se están organizando. Por ejemplo, al diseñar un sistema de organización de libros, no es suficiente decir que la descripción de un libro se estructura utilizando “Abstracción en la descripción del recurso”.)

Al diseñar un sistema de organización podemos optar por reutilizar un modelo estándar. Por ejemplo, ^[22]

Si no existe tal estándar, o los estándares existentes no se ajustan a nuestras necesidades, podemos crear un nuevo modelo para nuestro dominio específico. Pero no solemos crear un nuevo metamodelo: en cambio, tomaremos decisiones entre los metamodelos, como ^[23]

Especificación de Vocabularios y Esquemas

Crear un modelo para descripciones de recursos en un dominio particular implica especificar los elementos comunes de esas descripciones y dar a esos elementos nombres estándar. (Consulte “El proceso de descripción de recursos”) El modelo también puede especificar cómo se organizan estos elementos en estructuras más grandes, por ejemplo, cómo se ordenan en listas anidadas en árboles. Los metamodelos varían en las herramientas que proporcionan para especificar la estructura y composición de los modelos específicos de dominio, y en la madurez y robustez de los métodos para diseñarlos. ^[24] Cada RDF y XML proporcionan diferentes herramientas específicas de metamodelo para definir un modelo para un dominio específico. Pero no todos los metamodelo proporcionan tales herramientas.

En esquemas. Un esquema XML que define un modelo de dominio proporciona un vocabulario de términos que se pueden usar como nombres de elementos y atributos en documentos XML que se adhieren a ese modelo. Por ejemplo, el esquema de Onix para Libros especifica que un autor de un libro debe llamarse Colaborador, y que el recuento de páginas debe llamarse una extensión. Un esquema XML también define reglas sobre cómo esos elementos, atributos y su contenido se pueden organizar en estructuras de nivel superior. Por ejemplo, el Onix para Libros especifica que la descripción de un libro debe incluir una lista de elementos Contributor, que esta lista debe tener al menos un elemento en ella, y que cada elemento Contributor debe tener un hijo ContributorRole elemento.

Si un ^[25] Asociar un esquema con una validación: verificar automáticamente que los términos de vocabulario se estén utilizando correctamente. ^[26]

Si dos descripciones comparten lo mismo Describiendo Relaciones y Estructuras.)

Las estructuras de árbol pueden variar considerablemente mientras se ajustan al metamodelo XML Infoset. Los usuarios de XML suelen especificar reglas para verificar si ciertos patrones aparecen en un documento XML (validación a nivel de documento). Esto se hace con menos frecuencia con RDF, porque las gráficas que se ajustan al metamodelo RDF tienen todas la misma estructura: todas son conjuntos de triples. Esta estructura compartida facilita la combinación de diferentes descripciones de RDF sin preocuparse por verificar la estructura a nivel de documento. No obstante, a veces es deseable verificar descripciones a nivel de documento, como cuando se requiere parte de una descripción. Al igual que con XML, si los consumidores de esas descripciones quieren afirmar que esperan que esas descripciones tengan cierta estructura (como una propiedad requerida), deben verificarlas a nivel de documento.

Porque la Web Semántica. (Ver también “La web semántica y los datos enlazados”, así como más adelante en este capítulo.) ^[27]

Por ejemplo, el estándar de Descripción y Acceso a Recursos (RDA) para catalogar recursos bibliotecarios incluye un conjunto de vocabularios RDF que definen predicados utilizables en descripciones de catalogación. Uno de esos predicados es:

        <http://rdvocab.info/Elements/extentOfText>

que se define como “el número y tipo de unidades y/o subunidades que componen un recurso consistente en texto, con o sin ilustraciones acompañantes. ” El vocabulario especifica además que este predicado es un refinamiento de un predicado más general:

        <http://rdvocab.info/Elements/extent>

que se puede utilizar para indicar, “el número y tipo de unidades y/o subunidades que componen un recurso” independientemente de que sea textual o no.

JSON carece de cualquier forma estandarizada de definir qué términos se pueden usar. Eso no significa que no se pueda usar un vocabulario estándar al crear descripciones usando JSON, solo que no hay una forma acordada de usar JSON para comunicar qué vocabulario se está usando, y no hay forma de verificar automáticamente que se esté usando correctamente.

Control de Valores

Hasta el momento, nos hemos centrado en cómo los modelos especifican vocabularios de términos y cómo esos términos pueden ser utilizados en las descripciones. Pero los modelos también pueden constreñir los valores o el contenido de las descripciones. En ocasiones, un solo modelo definirá tanto los términos que se pueden usar para los nombres de propiedades como los términos que se pueden usar para los valores de las propiedades. Por ejemplo, un ^[28]

A menudo, sin embargo, hay vocabularios separados y especializados de términos destinados a ser utilizados como valores de propiedad en las descripciones de recursos. Por lo general, estos vocabularios proporcionan valores para su uso dentro de declaraciones que describen de qué se trata un recurso. Ejemplos de tales vocabularios de temas incluyen los encabezamientos de materias de la Biblioteca del Congreso (LOC-SH) y los encabezamientos de materias médicas (MeSH). ^[29] Otros vocabularios pueden proporcionar nombres autoritarios para personas, corporaciones o lugares. Los esquemas de clasificación son otro tipo de vocabulario, proporcionando los nombres de las categorías para su uso como valores en declaraciones descriptivas que clasifican los recursos.

Debido a que diferentes metamodeles toman diferentes enfoques para especificar vocabularios, generalmente habrá diferentes versiones de estos vocabularios para su uso con diferentes metamodeles. Por ejemplo, los LCSH están disponibles como XML conforme al esquema Metadata Authority Description Standard (MADS), y como RDF usando el Simple Knowledge Organization System (SKOS) vocabulario.

Especificar un vocabulario es solo una forma en que los modelos pueden controlar qué valores se pueden asignar a las propiedades. Otra estrategia es especificar qué tipos de valores se pueden asignar. Por ejemplo, un modelo para descripciones de libros puede especificar que el valor de una propiedad pages debe ser un entero positivo. O podría ser más específico; un catálogo de cursos podría dar a cada curso un identificador que contenga un código de departamento de dos letras seguido de un número de curso de 1-3 dígitos. Especificar un tipo de datos como este con una expresión regular reduce el conjunto de valores posibles para la propiedad sin tener que enumerar todos los valores posibles. (Ver la barra lateral.)

Además o en lugar de especificar un tipo, un modelo puede especificar un esquema de codificación para valores. Un esquema de codificación es un sistema de escritura especializado o sintaxis para tipos particulares de valores. Por ejemplo, un modelo como Atom para describir contenido web sindicado requiere una fecha de publicación. Pero hay muchas formas diferentes de escribir fechas: 9/2/76, 2 de septiembre de 1976, 2 de septiembre de 1976, etc. Atom también especifica un esquema de codificación para los valores de fecha. El esquema de codificación es RFC3339, un estándar para escribir fechas. Al usar RFC3339, siempre se escribe una fecha usando el mismo formulario: 1976-09-02. ^[30]

Expresiones Regulares

Las expresiones regulares se han utilizado para describir patrones en documentos de texto desde los primeros días de la computación y se generalizaron cuando Ken Thompson las incorporó a las primeras herramientas de procesamiento de textos UNIX., como ed y grep. Hay demasiadas variaciones de sintaxis de expresión regular para que las detallemos aquí, pero vale la pena considerarlas brevemente mientras estamos en el tema de controlar valores. ^[31]

Las expresiones regulares son empleadas por las modernas herramientas de procesamiento de texto con fines de selección y recuperación. En aplicaciones de búsqueda y reemplazo, uno podría buscar la cadena “Capítulo [1-5]” para expresar su intención de seleccionar los capítulos 1 a 5, o “it [']? s” para ubicar cada uso de “es” y “su” en un manuscrito; esta capacidad es muy valorada por cualquiera que haya tenido que editar un libro. Los programadores y modeladores de datos utilizan expresiones regulares para describir esquemas de codificación esperados cuando diseñan documentos, elementos de datos, bases de datos y esquemas de codificación. Experimenta el procesamiento de expresiones regulares cuando ingresa un número de teléfono o código postal en un formulario basado en la web. Muchos lenguajes de modelado de datos, programación y esquemas XML emplean expresiones regulares para controlar la entrada de datos y la validación de valores. En el contexto del control de valores, podemos usar expresiones regulares para describir valores de datos tan variados como identificadores, nombres, fechas, números de teléfono y códigos postales. También podemos definir reglas para el manejo de espacios en blanco y puntuación dentro de un valor de datos.

Los esquemas de codificación a menudo se definen junto con identificadores estandarizados. (Ver “Hacer Nombres Informativos”.) Por ejemplo, International Standard Book Numbers (ISBN) no son solo secuencias de números arábigos: son valores escritos usando el esquema de codificación ISBN. Este esquema especifica cómo separar la secuencia de números en partes, y cómo se debe interpretar cada una de estas partes. El ISBN 978-3-8218-4448-0 consta de cinco partes, las tres primeras de las cuales indican que el recurso con este identificador es 1) un producto de la industria editorial de libros, 2) publicado en un país de habla alemana, y 3) publicado por la editorial Eichborn.

Los esquemas de codificación pueden verse como modelos muy especializados de tipos particulares de información, como fechas o identificadores de libros. Pero debido a que especifican no sólo la estructura de esta información, sino también cómo debe escribirse, también podemos verlas como sistemas de escritura especializados. Es decir, los esquemas de codificación especifican cómo representar textualmente la información.

En la segunda mitad de este capítulo, nos centraremos en los temas involucrados en representar textualmente las descripciones de los recursos, escribirlas. Gráficos, árboles, diccionarios, listas y conjuntos son tipos generales de estructuras que se encuentran en diferentes metamodelos. Pensar en estos tipos amplios y cómo encajan o no se ajustan a las formas en que queremos modelar nuestras descripciones de recursos puede ayudarnos a seleccionar un metamodelo específico. Metamodeles específicos como los recursos y colecciones en nuestro dominio específico. Pero debido a que los metamodeles son abstractos y existen sólo a nivel conceptual, sólo pueden llevarnos hasta el punto. Si queremos crear, almacenar e intercambiar descripciones de recursos individuales, necesitamos hacer que las estructuras definidas por nuestros metamodeles abstractos sean concretas. Tenemos que escribirlos.

---

1. Esta discusión sobre las tarjetas de Batten se basa en (Lancaster 1968, páginas 28-32). La propia explicación de Batten está en (Batten 1951).

   
   

2. (Silman 1998). (Sebald 1995).

   
   

3. La técnica de diagramación de oraciones fue inventada a mediados del siglo XIX por Stephen W. Clark, un maestro de escuela neoyorquino; (Clark2010) es una reimpresión exacta de una edición de casi 100 años de antigüedad de su libro A Practical Grammar. Un reciente homenaje a Clark es (Florey 2012).

   
   

4. Es fácil subestimar el increíble poder de los sistemas perceptual y cognitivo humanos para aplicar la computación neuronal y el conocimiento para permitir que la visión y la audición parezcan automáticos. Las computadoras están mejorando en la extracción de características de señales visuales y auditivas para identificar y clasificar entradas, pero nuestro punto aquí es que ninguna de estas características se representa explícitamente en la entrada “blob” o “stream”. ”

   
   

5. Como comentamos anteriormente, una descripción oral de un recurso puede no ser especialmente útil en un sistema de organización porque las computadoras no pueden entenderlo fácilmente. Por otro lado, hay muchos contextos en los que una descripción oral sería especialmente útil, como en una visita guiada a un museo donde los visitantes pueden usar auriculares de audio.

   
   

6. Lo que se perdió fue la estructura antes invisible proporcionada por la gramática, que nos hizo asignar roles a cada uno de estos términos para crear una interpretación semántica.

   
   

7. Rara vez es práctico hacer las cosas lo más simples posible. Según Einstein, deberíamos esforzarnos por “Hacer que todo sea lo más simple posible, pero no más sencillo. ”

   
   

8. Este metamodelo estructural solo permite un valor por cada propiedad, lo que significa que no funcionaría para libros con múltiples autores o que discutan múltiples temas.

   
   

9. Ir en la otra dirección no es tan fácil, sin embargo: así como los diccionarios reales no admiten encontrar una palabra dada una definición, tampoco las estructuras de diccionario admiten encontrar una clave dado un valor.

   
   

10. El conjunto de información XML (Cowan2004)

    Document Design Matters, (Wilde y Glushko 2008b) señalan que “Si el diseñador de un formato de intercambio utiliza un metamodelo conceptual no XML porque parece ser un mejor ajuste para el modelo de datos, XML solo se usa como capa física para el modelo de intercambio. La capa lógica en este caso define el mapeo entre el modelo conceptual no XML, y cualquier reconstrucción de los datos del modelo de intercambio requiere que el consumidor sea plenamente consciente de este mapeo. En tal caso, es una buena práctica hacer que los usuarios de la API sean conscientes de que está utilizando un metamodelo no XML. De lo contrario, podrían tener la tentación de basar su implementación en un conjunto de ejemplos demasiado pequeños, creando implementaciones que son frágiles y fallarán en algún momento. ”

    
    

11. Técnicamente, lo que aquí se describe es referido como “árbol enraizado” por los matemáticos, quienes definen a los árboles de manera más general. Dado que los árboles utilizados como estructuras de datos son siempre árboles enraizados, aquí no hacemos la distinción.

    
    

12. Esta característica se basa en la existencia de un esquema XML. Un esquema XML puede declarar que ciertos atributos son de tipo ID, IDREF o IDREFS. Ya sea un DTD XML o uno de los muchos lenguajes de esquemas que se han desarrollado bajo los auspicios del W3C o ISO.

    
    

13. http://www.w3.org/TR/xml-infoset/.

    
    

14. El Infoset XML es uno de los muchos metamodelos para XML, incluyendo el DOM y XPath. Normalmente, un Infoset XML se crea como un subproducto del análisis de una instancia de documento XML bien formada. Un documento XML también puede ser informado por su DTD o esquema con información sobre los tipos de valores de atributo, y sus valores predeterminados. Los atributos de tipo ID, IDREF e IDREF proporcionan un mecanismo para la vinculación y transclusión de hipertexto intra-documento. Una instancia de documento XML puede contener definiciones de entidad y referencias que se expanden cuando se analiza el documento, ofreciendo así otra forma de transclusión.

    
    

15. Una instancia de documento XML bien formada, cuando se procesa, dará como resultado un conjunto de información XML, como se describe aquí. Los conjuntos de información también pueden construirse por otros medios, como la transformación a partir de otro conjunto de información. Consulte la sección de Infosets Sintéticos en http://www.w3.org/TR/xml-infoset/#intro.synthetic para más detalles.

    
    

16. El Infoset contiene conocimiento de si todas las declaraciones relacionadas han sido leídas y procesadas, el URI base de la instancia del documento, información sobre tipos de atributos, comentarios, instrucciones de procesamiento, entidades y notaciones no analizadas, y más.

    Una instancia de documento XML bien formada para la que haya esquemas asociados, como un DTD, puede aportar información al Infoset. En particular, los esquemas pueden asociar tipos de datos con elementos de información de elementos y atributos, y también pueden especificar valores predeterminados o fijos para los atributos. Un DTD puede definir entidades a las que se hace referencia en la instancia del documento y que se expanden en el lugar cuando se procesan. Estas contribuciones pueden afectar el valor de verdad del documento.

    
    

17. El estándar SGML establecía explícitamente que la documentación que describe o explica un DTD es parte de la definición del tipo de documento. La implicación es que un esquema no se trata solo de definir la sintaxis, sino también de la semántica. Además, dado que los DTD no permiten describir todas las restricciones posibles, como las restricciones de coocurrencia, la documentación podría servir como guía humano-consumible para implementadores, creadores de contenido y consumidores.

    
    

18. Los tipos de atributos pueden declararse en un DTD XML o esquema. Los atributos cuyo tipo es ID deben tener un valor de nombre XML válido que sea único dentro de ese documento XML; un atributo de tipo IDREF cuyo valor corresponde a un ID único tiene una propiedad de “referencias” cuyo valor es el nodo elemento que corresponde al elemento con ese ID . Un atributo de tipo IDREFS cuyo valor corresponde a una lista de ID único tiene una propiedad de “referencias” cuyo valor es una lista de nodos de elemento que corresponde al elemento o elementos con ID coincidentes.

    
    

19. Inclusiones XML (XInclude) es (Marsh, Orchard y Veillard 2006).

    
    

20. XML Linking Language (XLink) es (DeRose, Maler, Orchard y Walsh 2010).

    
    

21. Dentro de la DTD del documento, uno simplemente declara la entidad y su valor correspondiente, que podría ser cualquier cosa, desde un documento completo hasta una frase y luego puede ser referenciada en su lugar dentro de la instancia del documento XML. La referencia de entidad se sustituye por el valor de entidad en el Infoset XML. Las entidades, como envoltorios nombrables, desaparecen efectivamente en su camino hacia el Infoset XML.

    
    

22. El Intercambio de Información en Línea (ONIX) es el estándar internacional para representar y comunicar información de productos de la industria del libro en forma electrónica: http://www.editeur.org/11/Books/.

    
    

23. No asuma la tarea de crear un nuevo (Bray 2005) para obtener asesoramiento sobre cómo reducir el riesgo de diseño de vocabulario si no puede encontrar uno existente que satisfaga sus requisitos.

    
    

24. Consulte (Glushko y McGrath 2005) para una síntesis de las mejores prácticas para crear lenguajes específicos de dominio en contextos de publicación técnica e intercambio de documentos de empresa a empresa. Se necesitan mejores prácticas para problemas grandes, mientras que los pequeños pueden ser atacados con métodos ad hoc.

    
    

25. A menos que un espacios de nombres. Por ejemplo, si un elemento llamado “título” significa el “título del libro” en un esquema y “el honorífico asociado a una persona” en otro, las instancias podrían tener elementos con prefijos de espacio de nombres como <book:title>La disciplina de la organización</book:title> y <hon :Título>Profesor</hon:title>. Los espacios de nombres son una fuente común de frustración en XML, porque parecen una solución demasiado complicada a un problema simple. Pero además de evitar colisiones de nombres, son importantes en la composición y organización de esquemas.

    
    

26. Lo que significa “correctamente” depende del lenguaje de esquema utilizado para codificar el modelo conceptual del tipo de documento. La familia de estándares XML incluye varios lenguajes de esquema que difieren en cuán completamente pueden codificar el modelo conceptual de un tipo de documento. La definición de tipo de documento (DTD) tiene su origen en la publicación y aplica bien las restricciones estructurales; expresa una fuerte tipificación de datos a través de recursos de documentación asociados. XML Schema Definition Language (XSD) es mejor para representar tipos de documentos transaccionales, pero su poder expresivo agregado tiende a hacerlo más complejo.

    
    

27. Por ejemplo, consulte Vocabularios abiertos vinculados en lov.okfn.org/dataset/lov/index.html.

    
    

28. Los valores de atributo se pueden limitar en un esquema especificando un tipo de datos, un valor predeterminado y una lista de valores potenciales. Los tipos de datos nos permiten especificar si se supone que un valor es un nombre, un número, una fecha, un token o una cadena de texto. Habiendo establecido el tipo de datos, podemos limitar aún más el valor de un atributo especificando un rango de valores, para un número o una fecha, por ejemplo. También podemos usar patrones de expresión regular para describir un tipo de datos como un código postal, número de teléfono o número ISBN. Especificar valores predeterminados y listas de valores legales para atributos simplifica la creación de contenido y los procesos de aseguramiento de la calidad. En Schematron, un lenguaje de esquema XML basado en reglas para hacer aserciones de prueba sobre documentos XML, podemos expresar restricciones entre elementos y atributos de formas que otros lenguajes de esquema XML no pueden. Por ejemplo, podemos expresar la restricción de que si <title>se proporcionan dos elementos, entonces cada uno debe contener un valor de cadena único y diferentes valores de atributo de idioma.

    
    

29. Consulte LOC-SH como http://id.loc.gov/authorities/subjects.html; MeSH en http://www.nlm.nih.gov/mesh/.

    
    

30. El Atom Publishing Protocol es IETF RFC 5023, (tools.ietf.org/html/rfc5023); una buena introducción es (Sayre 2005). IETF RFC es http://www.ietf.org/rfc/rfc3339.txt.

    
    

31. No existe una sola autoridad sobre el tema de las expresiones regulares o su sintaxis. Un buen punto de partida es el artículo de Wikipedia sobre el tema: http://en.Wikipedia.org/wiki/Regular_expression.