Índice1. OBJETIVOS.......................................................................................................................9

2. INTRODUCCIÓN.............................................................................................................10

CAPÍTULO 1. VISIÓN GENERAL DE LOS METADATOS.................................................12

1.¿QUÉ SON LOS METADATOS? ................................................................................12

1.1. DEFINICIÓN DEL CONCEPTO DE METADATO................................................12

1.2. CONCEPTOS ASOCIADOS AL USO DE LA METAINFORMACIÓN................13

1.3. DISTINICIÓN ENTRE DATOS Y METADATOS..................................................14

1.4. USO DE LOS METADATOS................................................................................15

1.4.1. OBJETIVO Y MOTIVACIÓN DE LOS METADATOS...................................15

1.4.2. CONTEXTOS DE APLICACIÓN DE LOS METADATOS.............................17

1.4.3. CICLO DE VIDA DE LOS METADATOS......................................................18

1.4.3.1. CREACIÓN DE METADATOS. ............................................................18

1.4.3.2. MANIPULACIÓN DE METADATOS......................................................19

1.4.3.3. ALMACENAMIENTO/DESTRUCCIÓN DE METADATOS....................20

1.5. CLASIFICACIÓN DE LOS METADATOS...........................................................20

1.6. ALGUNAS CRÍTICAS AL USO DE LOS METADATOS......................................24

CAPÍTULO 2. ESTÁNDARES DE METADATOS MÁS EXTENDIDOS.............................25

1. ESTANDARIZACIÓN E INTEROPERABILIDAD DE LOS METADATOS..................25

1.1. LA ESTANDARIZACIÓN......................................................................................25

1.2. INTEROPERABILIDAD DE LOS METADATOS..................................................27

1.2.1. INTRODUCCIÓN..........................................................................................27

1.2.2. ¿QUÉ ES LA INTEROPERABILIDAD?........................................................28

1.2.3. ¿QUÉ ES UN SCHEMA DE METADATOS?................................................28

1.2.4. INTEROPERABILIDAD DE METADATOS A DIFERENTES NIVELES.......29

1.3. INTEROPERABILIDAD EN EL NIVEL DE SCHEMA..........................................31

1.3.1. DERIVACIÓN................................................................................................32

1.3.2. PÉRFILES DE APLICACIÓN........................................................................33

1.3.3. CROSSWALKS.............................................................................................35

1.3.4. SWITCHING-ACROSS.................................................................................38

1.3.5. FRAMEWORK DE METADATOS.................................................................39

1.3.6. REGISTRO DE METADATOS......................................................................41

1

2. EL ESTÁNDAR ID3.....................................................................................................42

2.1. INTRODUCCIÓN..................................................................................................42

2.1. ID3 VERSIÓN 1....................................................................................................43

2.2. ID3 VERSIÓN 2....................................................................................................44

3. EL ESTÁNDAR DUBLIN CORE..................................................................................45

3.1. INTRODUCCIÓN..................................................................................................45

3.2. CARACTERÍSITICAS Y OBJETIVOS DE DUBLIN CORE..................................45

3.3. ELEMENTOS DUBLIN CORE..............................................................................46

3.4. EL ESQUEMA Y LOS CALIFICADORES DE DUBLIN CORE............................49

3.5. EJEMPLOS: METADATOS DC CON ETIQUETAS DE DISTINTOS

ESTÁNDARES ...........................................................................................................55

4. EL ESTÁNDAR DE METADATOS LOM.....................................................................57

4.1. INTRODUCCIÓN..................................................................................................57

4.2. CATEGORÍAS EN LAS QUE SE AGRUPAN LOS METADATOS LOM.............59

4.2.1. CATEGORÍA GENERAL...............................................................................59

4.2.2. CATEGORÍA LIFECYCLE............................................................................60

4.2.3. CATEGORÍA META-METADATA.................................................................61

4.2.4. CATEGORÍA TECHNICAL...........................................................................62

4.2.5. CATEGORÍA EDUCATIONAL......................................................................63

4.2.6. CATEGORÍA RIGTHS..................................................................................64

4.2.7. CATEGORÍA RELATION..............................................................................64

4.2.8. CATEGORÍA ANNOTATION .......................................................................65

4.2.9. CATEGORÍA CLASSIFICATION..................................................................65

4.3. REPRESENTACIÓN DE LOS METADATOS LOM EN XML...............................65

5. EL ESTÁNDAR DE METADATOS RDF......................................................................70

5.1. INTRODUCCIÓN..................................................................................................70

5.2. MODELO BÁSICO DE RDF.................................................................................71

5.3. EJEMPLO DE UNA SENTENCIA RDF................................................................72

5.4. SINTAXIS BÁSICA RDF......................................................................................74

5.4.1 SINTAXIS SERIALIZADA COMPLETA.........................................................74

5.4.2. SINTAXIS BÁSICA ABREVIADA..................................................................77

5.5. ESQUEMA RDF (SCHEMA RDF O RDFs)..........................................................80

6. EL ESTÁNDAR DE METADATOS MPEG-7...............................................................81

2

6.1 INTRODUCCIÓN...................................................................................................81

6.2. OBJETIVO Y ALCANCE DE MPEG-7.................................................................82

6.3. PARTES EN LAS QUE SE DIVIDE MPEG-7.......................................................86

6.4. MDS DE MPEG-7 (ESQUEMAS DE DESCRIPCIONES MULTIMEDIA)............88

6.4.1. ELEMENTOS BÁSICOS DE UN DMS.........................................................89

6.4.2. LA GESTIÓN DE CONTENIDOS.................................................................90

6.4.3. DESCRIPCIÓN DEL CONTENIDO..............................................................91

6.4.4. ORGANIZACIÓN DE LOS CONTENIDOS MULTIMEDIA...........................92

6.4.5. NAVEGACIÓN Y ACCESO A UN CONTENIDO..........................................92

6.4.6. ITERACIÓN CON EL USUARIO...................................................................93

7. EL ESTÁNDAR DE METADATOS TV-ANYTIME.......................................................93

7.1. ¿QUÉ ES EL TVA FORUM?................................................................................93

7.2. INTRODUCCIÓN AL ESTÁNDAR DE METADATOS TVA.................................95

7.3. METADATOS TV-ANYTIME: FASE I...................................................................95

7.3.1. PARTE A. ESQUEMAS DE METADATOS...................................................96

7.3.1.1. MODELO DE DATOS DE TV-ANYTIME...............................................96

7.3.1.2. TIPOS DE METADATOS.....................................................................101

7.3.2. PARTE B. ASPECTOS DEL SISTEMA......................................................114

7.3.2.1. ASPECTOS DEL SISTEMA EN UN AMBIENTE UNIDIRECCIONAL 114

7.3.2.2. ASPECTOS DEL SISTEMA EN REDES BIDIRECCIONALES...........118

CAPÍTULO 3. USO DE METADATOS EN PROYECTOS REALES DE I+D+i..................120

1. METADATOS Y LA WEB SEMÁNTICA...................................................................120

1.1. INTRODUCCIÓN................................................................................................120

1.2. LA WEB SINTÁCTICA.......................................................................................123

1.3. BÚSQUEDA BASADA EN CADENAS DE CARACTERES...............................124

1.4. LA WEB SEMÁNTICA........................................................................................125

1.5. INFRACTRUCTURA DE LA WEB SEMÁNTICA ..............................................126

1.5.1. XML Y LA WEB SEMÁNTICA ....................................................................129

1.5.2. METADATOS Y RDF..................................................................................132

1.5.3. ONTOLOGÍAS............................................................................................138

1.5.4. OWL ...........................................................................................................141

2. METADATOS Y LA INICIATIVA DVB-H...................................................................142

2.1. INTRODUCCIÓN ...............................................................................................142

3

1.1. COMPARACIÓN ENTRE DVB-H Y DMB......................................................144

2.2. ARQUITECTURA Y FUNCIONAMIENTO DE DVB-H.......................................145

2.2.1. FUNCIONAMIENTO BÁSICO.....................................................................147

2.3. IP DATACAST OVER DVB-H (IPDC)................................................................148

2.3.1. ARQUITECTURA IPDC..............................................................................149

2.3.2. PILA DE PROTOCOLOS IPDC..................................................................150

2.4. ESG (ELECTRONIC SERVICES GUIDE).........................................................152

2.4.1. ADQUISICIÓN DE UNA ESG.....................................................................153

2.4.2. ESTRUCTURA DE UNA ESG....................................................................155

2.5. METADATOS EN LA ESTRUCTURA DE LOS FRAGMENTOS DE UNA ESG

...................................................................................................................................156

2.5.1. METADATOS EN EL FRAGMENTO SERVICE.........................................157

2.5.2. METADATOS EN EL FRAGMENTO SERVICEBUNDLE..........................158

2.5.3. METADATOS EN EL FRAGMENTO CONTENT........................................160

2.5.4. METADATOS EN EL FRAGMENTO SCHEDULE-EVENT........................161

2.5.5. METADATOS EN EL FRAGMENTO ACQUISITION.................................162

2.5.6. EJEMPLO DE UNA ESG............................................................................163

6. CONCLUSIONES..........................................................................................................165

7. BIBLIOGRAFÍA..............................................................................................................167

4

ÍNDICE DE FIGURASFigura 1. Varios niveles de proyectos de metadatos. Página 30.

Figura 2. Ejemplo de derivación de schemas. Página 32.

Figura 3. Ejemplo de un “Perfil de Aplicación” consistente de metadatos procedentes de uno o más namespaces (sets de elementos). Página 34.

Figura 4. Establecimiento de un crosswalk entre dos schemas de metadatos. Página 36.

Figura 5. Crosswalking relativo y absoluto. Página 37

Figura 6. Diferentes grados de equivalencia entre elementos que han sufrido un crosswalks entre dos schemas distintos. A1 y B1 representan elementos de los schemas A y B. Página 37.

Figura 7. Utilización de Switching-across cuando tenemos múltiples schemas involucrados. Página 38.

Figura 8. Crosswalk de CDWA a siete schemas diferentes. Página 39.

Figura 9. Schemas asociados a un Framework. Página 40.

Figura 10. Un registro de metadatos relacionado con varios schemas. Página 41.

Figura 11. Estructura general de metadatos LOM. Página 58.

Figura 12. Estructura del metadato general. Página 59.

Figura 13. Estructura del metadato lifecyle. Página 60.

Figura 14. Estructura del metadato metametadata. Página 61.

Figura 15. Estructura del metadato technical. Página 62.

Figura 16. Estructura del metadato educational. Página 63.

Figura 17. Estructura del metadato rigths. Página 64.

Figura 18. Estructura de metadatos LOM en XML. Página 66.

Figura 19. Codificación XML de metadatos LOM. Página 67.

Figura 20. Estructura gramatical para la codificación de la categoría general. Página 68.

Figura 21. Codificación XML del metadato general. Página 69.

Figura 22. Modelo de grafos de una sentencia en RDF. Página 73.

5

Figura 23. Modelo de grafos de un sentencia RDF más completa. Página 73.

Figura 24. Modelo de grafos de una sentencia completa en RDF. Página 74.

Figura 25. Código explicativo de la sintaxis básica serializada de RDF. Página 76.

Figura 26. Código con declaración de esquemas RDF. Página 77.

Figura 27. Variante del código de la figura 25. Página 77.

Figura 28. Variante del código de la figura 25. Página 77.

Figura 29. Código RDF abreviado utilizando propiedades no repetidas. Página 78.

Figura 30. Código RDF abreviado con elementos Description. Página 78.

Figura 31. Código RDF abreviado con elementos Description ( ejemplo refinado). Página 79.

Figura 32. Código RDF abreviado con elementos Description con sus atributos como parte del elemento Creator. Página 79.

Figura 33. Código RDF abreviado trabajando con la propiedad type del elemento Description. Página 79.

Figura 34. Ejemplo declaración RDFschema. Página 80.

Figura 35. Relaciones entre los diferentes elementos de MPEG-7.Página 83.

Figura 36. Alcance de MPEG-7. Página 84.

Figura 37. Representación de una aplicación en MPEG-7. Página 85.

Figura 38. Resumen de los Esquemas de Descripción de Multimedia. Página 89.

Figura 39. Flujo de metadatos y contenidos. Página 97.

Figura 40. Modelo de relaciones básicas entre entidades TV-Anytime. Página 99.

Figura 41. Metadatos referenciados mediante un CRID. Página 100.

Figura 42. Relaciones existentes entre los principales tipos de metadatos TV-Anytime. Página 100.

Figura 43. Modelo de descripción de contenidos en TV-Anytime. Página 102.

Figura 44. Modelo de un metadato BasicContentDescriptionType. Página 103.

Figura 45. Modelo de un metadato AVAttributesType. Página 104.

Figura 46. Modelo de datos de los metadatos de Información de Programa. Página 104.

Figura 47. Modelo de datos de los metadatos de información de grupo de programas. Página 105.

6

Figura 48. Modelo de datos de una entidad Program Location. Página 106.

Figura 49. Modelo del metadato ProgramLocationType. Página 106.

Figura 50. Modelo del metadato ScheduleEventType. Página 107.

Figura 51. Modelo del metadato OnDemandProgramtype. Página 108.

Figura 52. Descripción del metadato InstanceDescriptionType. Página 108.

Figura 53. Modelo del metadato ServiceInformationType. Página 109.

Figura 54. Modelos de los metadatos utilizados en TV-Anytime para crear un historial de las acciones de un usuario. Página 110.

Figura 55. Metadatos de descripción de las preferencias de los usuarios. Página 112.

Figura 56. Modelo de segmentación de un programa para un sistema TV-Anytime. Página 112.

Figura 57. Modelos de metadatos de segmentación. Página 114.

Figura 58. Proceso de descripción de metadatos para la entrega sobre un enlace unidireccional. Página 114.

Figura 59. Modelo de fragmentación de una descripción con metadatos TVA. Página 115.

Figura 60. Modelo de encapsulación de metadatos de descripción TVA. Página 117.

Figura 61. Modelo de uso de la indexación de contenedores TVA. Página 118.

Figura 62. Código HTML. Página 123.

Figura 63. Interpretación de un código HTML. Página 124.

Figura 64. La Web semántica como modelo de capas.(Tim Berners-Lee,2001). Página 127.

Figura 65. Pantalla capturada del OpenOffice. Página 130.

Figura 66. Parte del código XML utilizado por Sun para crear la pantalla de OpenOffice. Página 131.

Figura 67. Típico registro bibliográfico consistente en un conjunto de metadatos, señalados por flechas. Base de datos de LISA. Página 133.

Figura 68. Descripción de una página Web. Es recurso está rodeado por un circulo, los metadatos marcados mediante flechas. Página 135.

Figura 69. Espacio web representado a modo de grafo. Página 136.

Figura 70. Serialización del grafo de la figura 69. Página 136.

7

Figura 71. Representación de la relación entre documentos primarios y secundarios. Página 137.

Figura 72. Representación de una ontología de periféricos de un ordenador. Página 140.

Figura 73. Representación en OWL de la ontología anterior. Página 141.

Figura 74. Comparativa de sistemas de televisión en movilidad. Página 143.

Figura 75. Esquema de funcionamiento DVB-H. Página 146.

Figura 76. Sistema típico de la arquitectura IPDC. Página 149.

Figura 77. Diagrama de una Arquitectura global que usa IPDC sobre DVB-H. Página 150.

Figura 78. Pila de protocolo IP-Datacast sobre DVB-H. Página 151.

Figura 79. Ejemplo de un contenido con un servicio ofrecido con IPDC sobre DVB-H. Página 151.

Figura 80. Modelo de adquisición de una ESG y de un servicio. Página 154.

Figura 81. Modelo de relaciones entre los fragmentos de la ESG. Página 155.

Figura 82. Modelo del metadato ServiceType. Página 157.

Figura 83. Modelo del metadato ServiceBundleType. Página 159.

Figura 84. Metadatos del fragmento Content. Página 160.

Figura 85. Metadatos del fragmento ScheduleEvent. Página 161.

Figura 86. Metadatos del fragmento Acquisition. Página 162.

Figura 87. Metadatos del fragmento Purchase. Página 163.

Figura 88. Modelo XML de una ESG. Página 164.

8

1. OBJETIVOS

Este proyecto surge con la idea de sacar del olvido y presentar al gran público unos elementos que creemos de gran utilidad, los metadatos. Elementos que podemos utilizar como una herramienta, cuyo potencial no dejará de crecer en los próximos años. Aunque el mundo especializado no ha dejado nunca de lado los metadatos, no se ha conseguido dar la repercusión pública que creo que se merecen, y es con ese fin, con el que inicié la ejecución de este proyecto.

El proyecto pretende servir de altavoz que incite la curiosidad por estos elementos, permitiendo poner en contacto a incipientes investigadores con estas potentes herramientas. La idea es que este proyecto sirva de chispa que encienda la mecha de la imaginación de los lectores, de manera que gracias a ella y a la ayuda de los metadatos, se consigan encontrar soluciones a problemas procedentes de los campos más diversos, desde la medicina hasta la educación, pasando por las tecnologías de la información.

Un lector ávido de nuevas ideas y de herramientas que le permita encontrar soluciones a problemas que continuamente se plantean a su alrededor, con una mentalidad lo suficientemente abierta a nuevos conceptos, podrá encontrar en las sencillas líneas que componen el proyecto, un incentivo que despierte en él la curiosidad suficiente como para ver que estos elementos ofrecen un nuevo mundo de posibilidades.

Para conseguir despertar la curiosidad del lector dividimos el proyecto en tres objetivos básicos, que se corresponden con los tres capítulos principales del proyecto.

1.Explicar de forma sencilla y clara qué son los metadatos y cuáles son algunas de sus principales bondades.

2.Explicar, de forma breve y concisa, algunos de los estándares de metadatos más extendidos. Esto se lleva a cabo con la idea de que, a modo de baliza informativa, el lector pueda dilucidar algunas de las herramientas que hoy por hoy se utilizan en el mundo de los metadatos. De manera que pueda filtrar qué herramienta, basada en el uso de los metadatos, es la más conveniente de utilizar a la hora de encontrar una solución a su problema.

3.Mostrar, en un par de ejemplos, cómo los metadatos se están usando en proyectos I+D+i. Se pretende mostrar cómo los metadatos están abriendo nuevos caminos y soluciones a problemas que se plantean en sociedades cada vez más digitalizadas. Aunque el conjunto de ejemplos no abarca todo el potencial que ofrecen los metadatos, sí nos dan una idea de cómo se pueden utilizar y qué problemas nos pueden solucionar.

Es a partir de este tercer objetivo donde entra en juego el lector, imaginando como estos sencillos y útiles compañeros (los metadatos) pueden ser la solución a problemas de clasificación, compresión, contextualización o estructuración, de innumerables aplicaciones en gran diversidad de campos. Con el objetivo de ayudar a encontrar estas soluciones, o al menos de ayudar a imaginarlas, se ha planteado este proyecto .

9

2. INTRODUCCIÓN

El proyecto se estructura en una serie compuesta de tres capítulos. En cada uno de estos capítulos se intenta dar cumplimiento a cada uno de los tres objetivos que nos marcamos al iniciar la ejecución del proyecto.

El capítulo primero pretende acercar al lector al concepto de los metadatos. Dicho acercamiento comienza, como no podía ser de otra forma, explicando qué entendemos por metadatos y cuáles han sido las distintas definiciones que se han ido dando a dicho concepto. Así mismo, en este capítulo se hace una referencia a la distinción entre metadatos y datos, haciendo ver al lector que en algunas ocasiones tal distinción se hace realmente complicada, debido a la amplitud que muestra el concepto de metadato.

El capítulo continúa con una serie de apartados que tienen como finalidad hacer ver al lector para qué se usan los metadatos y cuáles son los contextos en los que se emplean. Así pues, con la lectura de estos apartados se pretende tener una idea de lo que nos puede ofrecer el uso de los metadatos, la multitud de problemas para los que pueden ser la solución, y la variedad de campos a los que pueden pertenecer esos problemas.

El capítulo termina mostrando el ciclo de vida que suelen tener los metadatos en cualquiera de la aplicaciones en las que se usen. Además, veremos algunas de las clasificaciones más importantes en las que se suelen agrupar. En la última parte del capítulo se comentan algunos de los inconvenientes que encontramos en el uso de los metadatos. Inconvenientes que, al menos bajo mi opinión y bajo la opinión de muchos expertos, no tienen la suficiente entidad como para detener el imparable avance que se está produciendo en el uso de estos elementos, día tras día.

El segundo capítulo tiene como objetivo principal mostrar al lector algunas de las potentes herramientas de metadatos de las que dispone. Herramientas basadas en el uso de determinados estándares de metadatos. Para ello, el capítulo comienza explicando al lector, qué es un estándar, qué utilidad tiene y cuáles son las partes genéricas en las que se divide, con el fin de cubrir una serie de objetivos.

Hay que tener en cuenta que los estándares son el resultado de esfuerzos internacionales, de gran entidad y envergadura, que pretenden crear un conjunto de metadatos que sirvan para solucionar determinados conjuntos de problemas.

Así para solucionar problemas referentes a la radiodifusión de contenidos televisivos o de radio, se crea el estándar de metadatos TV-Anytime, mientras que para facilitar la creación de aplicaciones que faciliten herramientas educacionales, se define el estándar LOM.

Ambos estándares, junto con cinco más, se comentarán en este capítulo, de forma que el lector tenga una idea de las herramientas que tiene a su disposición, para que pueda seleccionar aquella que más convenga a su problema.

No dejamos de resaltar que estos no son los únicos estándares de metadatos existentes, hay muchos más que pueden ser de gran utilidad y que sería bueno que el lector analizara. Sin embargo, los seleccionados aquí pueden servir como muestra, y como punto de partida para el lector.

En el último capítulo del proyecto intentamos mostrar, en un par de ejemplos reales, la

10

importancia de utilizar los metadatos. Son dos proyectos en los que las sociedades modernas, basadas en las tecnologías de la información, están invirtiendo grandes cantidades de recursos, tanto económicos como humanos. Grandes esfuerzos que pretenden traducirse en el uso de la televisión digital interactiva en los dispositivos móviles, tal es el caso del uso de metadatos en la tecnología DVB-H, o en la creación de la llamada Web Semántica. En ambos casos, los metadatos juegan un papel tan importante que simplemente, hoy por hoy, no se concibe la idea de que se puedan llevar a cabo sin su uso.

Como hemos dicho, el capítulo se estructura en dos ejemplos, el primero de los cuales es el proyecto de la Web Semántica. En esta parte se intenta dar una visión al lector sobre lo que hoy en día tenemos, qué se pretende hacer, y cómo los metadatos nos pueden ayudar a conseguir el objetivo marcado. Se indica también qué estándares de metadatos son los utilizados en dicho proyecto, que tiene como objetivo principal crear una web basada en la búsqueda de conceptos, y no en la búsqueda de cadenas de caracteres. Esto conlleva, que el uso de los metadatos se convertirán en una pieza fundamental en la creación de una nueva forma de “inteligencia computacional”.

El siguiente ejemplo es el proyecto DVB-H (Digital Video Broadcasting Handheld). La idea de DVB-H es poder ofrecer los servicios de la televisión interactiva en dispositivos de bolsillo. En DVB-H, son los metadatos quienes nos ofrecen un camino que permite a estos dispositivos móviles distinguir los flujos televisivos que reciben, además de permitir asociarlos a los servicios de valor añadido que acompañan a dichos flujos. Los metadatos permitirán que en los dispositivos móviles no sólo se pueda recibir la televisión digital, tal y como hoy la recibimos en nuestros televisores de salón, sino que además los usuarios podamos interactuar con los contenidos que estamos visionando.

Como se observa, este último capítulo nos ofrece una visión muy ambiciosa de lo que nos pueden ofrecer los metadatos, soluciones a una cantidad de problemas prácticamente infinitos, y abrirnos puertas que hasta ahora habían sido abiertas tan sólo, en el mundo de la ciencia ficción.

Por último cerramos el proyecto planteando las conclusiones que obtenemos de su realización, y mostrando la bibliografía utilizada en la realización del mismo.

11

CAPÍTULO 1. VISIÓN GENERAL DE LOS METADATOS

1.¿QUÉ SON LOS METADATOS?

1.1. DEFINICIÓN DEL CONCEPTO DE METADATO

Metadato es una palabra que toma su origen de la unión del término griego μετα (meta), que significa «después de» y del término latino datum (dato), cuyo significado se podría definir como «sobre datos». De esta forma se dice que los metadatos son datos que describen otros datos. Esta fue la primera definición del término, se dio allá por la década de los sesenta, y hoy por hoy, no sólo sigue vigente sino que además es la más extendida. La palabra metadato fue utilizada por primera vez en un artículo impreso en el año 1973, por parte del escritor Jack E. Myers. Posteriormente, en 1986 fue registrada como una marca, perteneciente a la empresa Metadata.

Aunque el concepto de metadatos hoy en día está íntimamente relacionado con el campo de la informática, atendiendo a la definición dada anteriormente, podemos afirmar que su utilización se lleva dando desde hace cientos o incluso miles de años. Obviamente, su uso no se conocía bajo el nombre de metadatos, aunque no por ello el hombre dejaba de utilizarlos. Un hombre que en el año 10000 a.c representaba en las paredes de una cueva una escena de un mamut, no estaba haciendo otra cosa que establecer una serie de metadatos que describían un ente físico y real como era el mamut.

Otro ejemplo bastante utilizado, y que nos da una idea muy cercana al uso que damos hoy en día a los metadatos, lo encontramos en las bibliotecas. En ellas se han utilizado, y aún hoy se siguen utilizando, las llamadas fichas técnicas. Dichas fichas especificaban autores, títulos, casas editoriales, estanterías, pasillos, plantas, etc. y tenían como objetivo no sólo el de localizar los libros de la manera más rápida posible, sino identificar el contenido de los mismos sin necesidad de leerlos. Se obtiene así una nueva definición del concepto de catalogación, entendiéndose como un proceso de generación de metadatos, donde esa información o conjunto de datos, no tiene otra misión más que la de describir otra determinada información, es a ese primer conjunto de datos a los que se pasa a denominar metadatos.

Siguiendo estos sencillos razonamientos encontramos muchos ejemplos del uso de los metadatos, no sólo para describir otra información, sino también objetos físicos. De este modo encontramos ejemplos sencillos y cotidianos del uso de los metadatos en las matrículas de los vehículos, la sinopsis de las películas en la parte posterior de un DVD, el título de una canción que se está reproduciendo en un mp3, etc. La lista puede ser tan interminable como podamos imaginar, puesto que el concepto de metadato deja abierto su uso a cualquier información que describa otra información u objeto.

Otra clase de definiciones trata de precisar el término como: «descripciones estructuradas y opcionales que están disponibles de forma pública para ayudar a localizar objetos» o «datos estructurados y codificados que describen características de instancias,

12

conteniendo informaciones para ayudar a identificar, descubrir, valorar y administrar las propias instancias descritas». Esta clase, surgió como respuesta a la crítica de que las declaraciones más simples son tan difusas y generales que dificultarán la tarea de acordarse de estándares. Aunque estas definiciones no son muy comunes, sí tienen cierta utilidad en el mundo de los lenguajes de programación.

De todas las definiciones existentes podemos extraer varios puntos cruciales (dato sobre el dato, concepto de objeto, recuperación de información) que nos pueden ser útiles para la realización de una nueva definición que aglutine a todas las publicadas hasta la fecha. De esta manera resulta posible concluir que metadato es:

“Aquella información descriptiva sobre el contexto, calidad, condición o características de un recurso, dato u objeto, que tiene la finalidad de facilitar su recuperación, autentificación, evaluación, procesamiento, preservación y/o interoperabilidad.”

1.2. CONCEPTOS ASOCIADOS AL USO DE LA METAINFORMACIÓNA continuación vamos a explicar algunos de los términos y conceptos asociados a los

metadatos, conceptos que aparecen siempre vinculados a ellos y cuya explicación nos contribuirá a entender mejor la teoría, el uso y el fundamento de la metainformación. Como veremos, estos conceptos se encuentran fuertemente relacionados con el campo de la informática, puesto que los metadatos poseen una importancia capital en la búsqueda, procesado y almacenamiento de la información digital, la cual es fuente de progreso y desarrollo en nuestra sociedad.

● DLO (Document Like Object) : En las bibliotecas digitales, y en general en la información distribuida en Internet, las colecciones digitales están formadas por documentos de diversos tipos; documentos de texto, imagen, audio y vídeo. Además estos pueden encontrarse en diversos formatos de codificación, y en esta situación entendemos los documentos como objetos informáticos o como objetos de información, que denominamos de forma abreviada DLOs. El acrónimo DLO, y el concepto asociado a él Document Like Object, surge en el seno del desarrollo del modelo de metadatos del Dublin Core, concretamente en el primer taller del DC en Ohio (Estados Unidos). Fue aquí donde se comenzaron a utilizar los DLOs para diferenciar nociones individuales que constituyen un objeto discreto, digno de una descripción individual a través de metadatos. Desde entonces, esta expresión está reconocida en la literatura sobre metadatos para aludir a los documentos de Internet (texto, imagen, audio o vídeo, etc.) y lo usamos para referirnos a una unidad documental o al documento digital mínimo, que forma parte de una colección digital, al que se le aplican metadatos para su descripción y recuperación.

● Colección digital: Conjunto de objetos de información (DLO) digitales o digitalizados, seleccionados y organizados para dar un acceso semántico, coherente y cualificado a la información en la Web. Una colección digital puede estar formada por distintos objetos de información, bien producidos originalmente en formato electrónico, bien digitalizados a partir de un original impreso. En el primer caso, normalmente, dan origen a "colecciones virtuales", donde el sistema sólo posee un conjunto de metadatos o elementos de metadatos que constituyen un subrogado digital de tal recurso (estas colecciones se denominan en el ámbito

13

anglosajón subject/information gateways), por otro lado, en el segundo caso hablamos de "colecciones digitales" propiamente dichas donde el sistema de información posee tanto los datos como los metadatos y éstos son igualmente la fuente de recuperación de aquéllos. Algunos ejemplos de colecciones virtuales temáticas son:

ADAM: http://www.adam.ac.uk

EdNA Online: http://www.edna.edu.au

LawAccess: http://www.lawaccess.nsw.gov.au

SOSIG: http://www.sosig.ac.uk

● Interoperabilidad: Desde un punto de vista informático, interoperabilidad se define como la habilidad que tiene un sistema o producto para trabajar con otros sistemas o productos sin un esfuerzo especial por parte del cliente. Este concepto tiene una importancia creciente a tenor de las colecciones digitales distribuidas que utilizan distintos esquemas de metadatos. A pesar de la complejidad de este concepto y de sus múltiples implicaciones para los sistemas de recuperación de información basados en metadatos, es un concepto clave al hablar de esquemas de metadatos y de la necesidad de compatibilizar todos ellos, para una recuperación de información integral en distintas colecciones de datos y metadatos distribuidos. La interoperabilidad entre distintos esquemas de metadatos puede realizarse de diversas formas, por ejemplo a través del funcionamiento de un protocolo (tipo OAI) o bien a través del mapeo o establecimiento de correspondencias entre informaciones en diferentes formatos (por ej. MARC-DC, FGDC-DC, etc.) para la conversión de elementos de metainformación que permita hacerlos compatibles.

1.3. DISTINICIÓN ENTRE DATOS Y METADATOSLos datos son símbolos que describen condiciones, hechos, situaciones o valores y se

caracterizan por no contener ninguna información. Así pues, un dato puede ser un número, una letra, un signo ortográfico o cualquier símbolo que represente una cantidad, una medida, una palabra o una descripción.

La importancia de los datos radica en su capacidad de asociarse dentro de un contexto para convertirse en información. Por sí mismos los datos no tienen capacidad de comunicar un significado, por tanto no pueden afectar el comportamiento de quien los recibe. Para ser útiles, los datos deben convertirse en una información que ofrezca un significado, un conocimiento, una serie de ideas o unas determinadas conclusiones.

Continuando con el razonamiento, decimos que la “información” es más bien una colección de hechos significativos y pertinentes para el organismo, la organización o la persona que los percibe. Una definición de información muy aceptada en el mundo académico es la siguiente:

“Información es un conjunto de datos significativos y pertinentes que describen sucesos o entidades.”

Una vez nos hemos aproximado a los conceptos de datos y de información,

14

estamos en situación de decir:

“Utilizamos los metadatos para aportar información sobre datos, mientras que, asociamos datos entre sí para aportar información sobre sucesos o entidades”.

Los límites que separan ambos conceptos se encuentran enormemente difuminados debido a la libertad con la que podemos interpretar el concepto de metadato. En muchísimas ocasiones encontramos verdaderos problemas a la hora de poder distinguir entre los metadatos y los datos en sí, siendo la mayoría de las veces imposible diferenciar ambos conceptos.

Pongamos un ejemplo con el que podamos asentar un poco las ideas; un poema es un grupo de datos que nos aportan una determinada información sobre entidades físicas, espirituales o sentimentales. Pero si un poema se encuentra adjuntado a una canción, que lo usa como texto, se puede considerar el poema como un grupo de metadatos. En esta situación los datos del poema funcionan tanto como metadatos de la canción como datos en sí mismos. De manera que, muchas veces, los datos son tanto "datos" como "metadatos".

Otro ejemplo muy sencillo lo encontramos en el título de un texto. El título es por un lado parte del texto en sí, de forma que es un dato más del conjunto de datos que conforman el texto. Pero por otro lado, el título se puede considerar como un metadato referente al propio texto. Es decir, es un metadato que aporta información sobre el conjunto de datos del texto.

En definitiva, para nosotros y a lo largo de todo el trabajo que se pretende desarrollar, los metadatos no se distinguirán de los datos en sí, de hecho lo serán, sólo que los entes a los que se refieren los limitaremos siempre a otros datos. De manera que volvemos a recurrir a la definición más extendida de los metadatos, que los trata como “Datos que describen a otros Datos”.

El hecho es que podemos incluso encontrar metadatos sobre metadatos, ya que como estamos diciendo los metadatos son datos en sí mismos. Aunque, a primera vista, parece absurdo, los metadatos sobre metadatos pueden ser muy útiles. Por ejemplo, fusionando dos imágenes y sus metadatos,puede ser muy importante deducir cuál es el origen de cada grupo de metadatos, por lo que podemos recurrir a metadatos que describan la creación de los metadatos que a su vez describen la imagen. No obstante, esta rama de los metadatos no la vamos a ampliar en este trabajo, y sólo queda aquí mencionada como una muestra más de las posibilidades que nos encontramos al usar los metadatos.

1.4. USO DE LOS METADATOS

1.4.1. OBJETIVO Y MOTIVACIÓN DE LOS METADATOS

Se podría decir que los metadatos se comenzaron a extender por nuestra sociedad debido al hecho de que gracias a su uso se podían responder de forma rápida y eficaz a un conjunto de interrogantes que habían aparecido. A través de los metadatos se puede conocer si un conjunto determinado de datos se ajusta o no a nuestras necesidades: ¿Dónde se originó?, ¿Qué pasos se siguieron para crearlo?, ¿Qué atributos contiene?, ¿Cómo están proyectados los

15

datos?, ¿Qué área geográfica cubre?, ¿Cómo obtener la información completa?, ¿Cuánto cuesta?, ¿Con qué persona se puede contactar para obtener una copia? etc . Como estas, otras muchas cuestiones, de ámbitos completamente diferentes, se pueden responder usando un conjunto de datos que nos ayuden a describir la información que estamos buscando o tratando.

Algunos de los principales objetivos de los metadatos podemos decir que son:

1) Inventariar el trabajo individual o de un grupo de trabajo (inventario).

2) Apoyar la búsqueda y compartir los datos.

3) Proveer, a los usuarios de los datos, información para su uso correcto.

4) Ayudar a una organización o compañía a organizar y dar valor agregado a su inversión en datos georeferenciados.

5) Proveer información sobre las bases de datos de que dispone una organización o compañía, de tal forma que se puedan formar catálogos de datos, lugares de acopio de datos y proveer información ágil a potenciales comercializadores de dichos datos.

6) Organizar los datos y mantener el conjunto de datos geoespaciales de la institución.

7) Proveer una guía para los usuarios de los datos en cuanto a su resolución espacial, sistema de coordenadas, datos y calidad.

8) Suministrar información que permita procesar los archivos recibidos de una fuente externa al usuario y facilitar el traslado de datos.

9) Catalogar la información de una institución y utilizarla en los centros de distribución.

En este trabajo vamos a dar una explicación más detallada de algunas de estas funciones que quedan cubiertas con el uso de los metadatos. Algunos de los ejemplos de metadatos más comunes hoy en día son los siguientes:

● El encabezamiento de un fichero multimedia (imagen, vídeo o audio).

● El resumen de un documento.

● El catálogo de una base de datos.

● Los términos asignados haciendo uso de un tesauro.

● Las palabras extraídas de un texto.

● Las fichas utilizadas en catálogos, en cualquier formato (ISBD, MARC, etc.).

● Las páginas amarillas.

En Internet podemos encontrarlos también en multitud de formas:

● Índices de documentos contenidos en una Intranet.

● Direcciones IP o DNS.

● Directorios X-500.

● Encabezamiento de mensajes de correo electrónico.

● Descripción de los archivos accesibles vía FTP.

16

● Términos extraídos por los motores de indización/búsqueda.

1.4.2. CONTEXTOS DE APLICACIÓN DE LOS METADATOS

Aunque el uso de los metadatos más frecuentemente mencionado es el de la recuperación de información: buscadores web, compresión de datos, bases de datos relacionadas, sistemas de ficheros etc. No debemos olvidar que se utilizan en ámbitos muy diversos, caso del desarrollo de la llamada inteligencia artificial (permitiendo deducir conclusiones automáticamente). También los usamos en campos que aparentemente no están relacionados, al menos de forma directa, con la informática o la electrónica. Campos como la geografía, la enseñanza o el arte han acabado recurriendo a los múltiples beneficios que suponen el uso de los llamados metadatos.

A lo largo de este trabajo se verán ejemplos y casos donde los metadatos han servido para fomentar grandes avances en estos campos, y algunos de dichos avances se explicarán de una forma más detallada.

Los metadatos se usan de forma extremadamente extendida para aumentar la precisión y disminuir el tiempo de procesado necesario en las consultas a buscadores. Usando estas informaciones adicionales los resultados que se consiguen son más precisos, y se le ahorra al usuario tener que realizar filtrados manuales complementarios, para poder adquirir ese grado de precisión.

En las comunicaciones máquina ser humano, siempre se plantea el problema semántico de que la máquina no comprenda el significado de los datos que el usuario le está enviando, de manera que no lleguen a entenderse y la comunicación no llegue a ser posible. En estas situaciones el uso de los metadatos adecuados pueden posibilitar la comunicación, debido a que estos se encuentran directamente relacionados con los datos.

Estos metadatos hacen posible una más eficaz compresión de los datos. Por ejemplo, supongamos que tenemos un vídeo, donde al usuario le interesa que el software sepa distinguir el primer plano del fondo. Podemos usar algoritmos de compresión diferentes, basados en metadatos que describan las imágenes de manera que tengamos metadatos asociados a los datos que representen el fondo, y metadatos asociados a los datos que represente el primer plano. De esta manera se puede mejora la cuota de compresión, este método se encuentra totalmente aceptado en estándares como MPEG-4 o MPEG-7, desarrollados por la ISO/IEC (International Standard Organization/International Electrotechnical Commission).

Por otro lado los metadatos también nos pueden facilitar el flujo de trabajo, permitiendo la conversión automática de datos de un formato a otro. Para ello necesitamos que los metadatos utilizados se encarguen de describir tanto el contenido como la estructura de los datos.

Otra posible aplicación, que encontramos al uso de los metadatos, es la presentación variable de datos. Si hay metadatos señalando los detalles más importantes de un conjunto de datos, se puede utilizar un programa que seleccione la forma de presentación más adecuada. Por ejemplo, si un teléfono móvil sabe dónde está localizada una persona en una imagen, tiene la

17

posibilidad de reducirlo a las dimensiones de su pantalla. Del mismo modo un navegador puede decidir presentar un diagrama a su usuario ciego en forma táctil o leída.

En realidad estas son sólo algunas de las posibles utilidades que nos ofrecen los metadatos, así como de posibles aplicaciones. A lo largo del documento que se expone aquí nos centraremos en algunas, concretando en la medida de lo posible, mientras que dejaremos de lado otras, ya que el abanico de campos y de aplicaciones en los que podemos usar los metadatos es realmente vasto.

1.4.3. CICLO DE VIDA DE LOS METADATOS.Aunque los metadatos difieren muchísimo unos de otros dependiendo del contexto

en el que se están utilizando, y por ende del estándar al cual pertenecen, podemos decir que en su mayoría cumplen un ciclo de vida que comprenden las fases de: creación, manipulación y almacenamiento/destrucción.

Vamos a pasar a hacer una breve explicación de cada una de las fases en las cuales dividimos dicho ciclo de vida.

1.4.3.1. CREACIÓN DE METADATOS.

Hay muchos expertos encargados del diseño de herramientas para la creación de metadatos que se plantean el interrogante de si los metadatos deben generarse una vez se ha creado un recurso o si por el contrario es durante la creación del recurso cuando estos deben ser creados. Existe una diferencia entre ambas situaciones que debemos, al menos, comentar; en el primer caso los metadatos se añaden como “adjetivos” que describirán un recurso una vez esté ya creado. Si pretendemos exportar el recurso no podemos utilizar los metadatos hasta que no se realice una reconstrucción completa de dicho recurso en su nueva localización. Una vez tengamos dicha reconstrucción, podremos llevar a cabo el análisis donde se verá qué parte del recurso se corresponde a qué parte de los metadatos de forma que podamos hacer uso de ellos.

Por el contrario, si integramos la producción de metadatos en el procedimiento de fabricación del recurso, a la vez que se genera el recurso podemos estar creando y asociando los metadatos que lo describen. Incluimos, por tanto, los metadatos como una parte más del propio recurso y evitamos posteriores reconstrucciones si queremos exportarlo.

Los metadatos deben describir todos los tipos y elementos que forman un determinado recurso mediante un lenguaje neutro, que pueda ser entendido por cualquier entidad. Es aquí donde radica la importancia de la utilización de estándares y schemas de metadatos, algo que discutiremos con más profundidad en el capítulo 2 de nuestro proyecto.

Aparte de la diferenciación hecha anteriormente, metadatos creados después de la creación de un recurso o durante la creación o utilización del mismo, se debe tener en cuenta una clasificación también decisiva a la hora de la creación de metadatos. Esta clasificación se basa en la diferenciación entre metadatos generados manualmente, semiautomáticamente o automáticamente.

18

El proceso manual puede ser extremadamente laborioso, hasta llegar a un grado en el que los seres humanos no puedan realizarlo. Este proceso dependerá del formato usado en los metadatos (estándares utilizados) y del volumen de metadatos que queramos generar para describir nuestros recurso. Cuanto mayor sea el volumen de metadatos que se asocian a un recurso, mayor será el grado de precisión en la descripción que obtendremos pero, por el contrario, más difícil se hace el proceso de creación de metadatos. Debido a esto, se consideran dos opciones alternativas a la creación manual de los metadatos.

La manipulación automática de metadatos, donde un software adquiere la información que necesita para describir un recurso sin ayuda externa. Aunque el desarrollo de unos algoritmos tan avanzados que nos permitan una creación automática de metadatos está siendo objeto de investigación, actualmente no es probable que las computadoras vayan a ser capaces de extraer todos los metadatos de un recurso de forma completamente automática.

En vez de ello, se considera que la producción semiautomática es una solución muhco más realista. En esta solución un servidor humano apoya el uso algoritmos autónomos, realizando aclaraciones de inseguridades o proporcionando información que el software es incapaz de extraer sin ayuda.

1.4.3.2. MANIPULACIÓN DE METADATOS

La gran utilidad de los metadatos radica en su manipulación de forma automática. Mediante el uso de estándares y schemas asociados, un software compatible puede extraer automáticamente una información extremadamente valiosa que nos permita adquirir, modificar o interpretar un recurso determinado. El hecho de poder realizarse este proceso sin la intervención humana nos ofrece un potencial enorme en un rango de aplicaciones casi ilimitado. A lo largo de este proyecto veremos algunos de los estándares más comunes de metadatos y un par de proyectos de gran relevancia, donde la manipulación automática de los metadatos es eje fundamental en el cual dichos proyectos se apoyan para poder ser implementados.

El problema surge si los datos, o los recursos, cambian una vez que los metadatos ya han sido creados y asignados. Esto obliga a que los metadatos deban cambiar también de forma que sigan describiendo con precisión al nuevo conjunto de datos (o al nuevo recurso). Aquí nos surge la pregunta de quién debe adaptar los metadatos a estos cambios. Hay modificaciones que pueden ser manejadas de forma sencilla y automática, pero hay otras donde la intervención de un ser humano es indispensable. Es en este punto donde la línea que separa la manipulación de la creación de los metadatos se hace más tenue y difusa. Por ello, se están realizando grandes esfuerzos, tanto humanos como económicos, para conseguir que la modificaciones sobre metadatos, o la creación de otros nuevos que sustituyan a los antiguos, sea un proceso lo más automatizado posible.

En este sentido se utiliza lo que se conoce como metaproducción, que consiste en el reciclaje de ciertas partes de los recursos para crear otros recursos, que son demandados, fusionando los metadatos afiliados. Este proceso no es nada trivial, especialmente si la información que se está tratando posee una relevancia jurídica, como por ejemplo ocurre con la gestión de los derechos digitales asociados a un determinado recurso.

19

1.4.3.3. ALMACENAMIENTO/DESTRUCCIÓN DE METADATOS

Hay dos posibilidades para almacenar metadatos: depositarlos internamente, en el mismo documento que los datos, o depositarlos externamente. Inicialmente, los metadatos se almacenaban internamente para facilitar la administración. Hoy, por lo general, se considera mejor opción la localización externa, ya que hace posible la concentración de metadatos para optimizar operaciones de busca.

Por el contrario, existe el problema de cómo se liga un recurso con sus metadatos. La mayoría de los estándares usan URIs, técnica para localizar documentos en la World Wide Web, pero este método propone otras preguntas, por ejemplo,¿qué hacer con documentos que no tienen URI?.

Para el caso mencionado anteriormente en la generación de metadatos, el Windows Presentation Foundation (WPF) Designer for Visual Studio, usa por lo general almacenes de metadatos basados en el uso de una API muy simple. Las tablas de atributos de metadatos se agregan llamando al método AddAttributeTable. Cuando una tabla se agrega al almacén de metadatos, los atributos definidos estarán disponibles en las consultas TypeDescriptor. Si ya se ha consultado un tipo y la tabla contiene atributos adicionales para este tipo, se provoca un evento (Refreshed) para informar de que los metadatos del tipo han cambiado. Una tabla de atributos es esencialmente un diccionario de sólo lectura, pero las claves y valores se calculan por separado.

Resulta eficaz realizar consultas en una tabla de atributos si contiene atributos para un tipo determinado. El conjunto real de atributos se crea a petición. Se llama al método GetCustomAttributes para recuperar los metadatos personalizados para un tipo determinado. Una tabla de atributos admite únicamente las propiedades de un tipo. Una tabla de atributos no admite atributos en campos o métodos. Si queremos profundizar más en el marco de WPF podemos recurrir al Microsoft Windows Design Metadata.

Por último, haremos una mención sobre la destrucción de los metadatos. En algunos casos es conveniente eliminar los metadatos junto con sus recursos, mientras que en otros es razonable conservar los metadatos, por ejemplo, cuando queremos supervisar cambios en un documento de texto. En ambos ambos casos, y en otros que puedan surgir, la destrucción de los metadatos generados es un paso importante que no se debe obviar a la hora de trabajar con metadatos.

Sin embargo, en esta introducción que estamos elaborando sobre el concepto de los metadatos, este tema lo vamos a relegar a un segundo plano. Esto no se debe a que el tema carezca de importancia, sino más bien a la vastedad del campo que nos atañe, que imposibilita poder expandirnos en todos los aspectos que forman dicho tema.

1.5. CLASIFICACIÓN DE LOS METADATOSPartiendo nuevamente de la idea de que los metadatos son datos acerca de otros

datos y/u objetos, podemos continuar diciendo que estos son utilizados para describir recursos, tanto digitalizados como no digitalizados, situados en un sistema distribuido dentro de un entorno de red.

20

Para que estos metadatos puedan ser realmente eficaces, se hace necesario que deban ser normalizados. Tradicionalmente, los metadatos incluyen las reglas de catalogación que se han estado utilizando en bibliotecas, tanto en los regímenes como en sus formatos.

Debido a la gran cantidad de información electrónica que se maneja en nuestra sociedad, se ha hecho necesario que los formatos utilizados se ampliasen, con el objetivo de poder reflejar las nuevas necesidades de localización de la información en redes de trabajo. Es por ello que se han terminado utilizando las reglas utilizadas en la catalogación electrónica. Este hecho refleja también un movimiento fuera de las tradicionales búsquedas de libros impresos en las bibliotecas, aportando una búsqueda mucho más amplia que se centra en todo tipo de datos y objetos, incluidos los objetos digitalizados.

De este modo, los metadatos pueden incluir información bibliográfica, tal y como sucede en catálogos de las bibliotecas tradicionales; descriptores, denominaciones de clasificación, resúmenes, etc., pero también pueden incluir datos estructurales sobre el tipo y el tamaño de los recursos, requisitos técnicos para su uso o necesarios para el acceso, las relaciones (temáticas, formales, referencias, citas, etc.), los términos y condiciones para la obtención y utilización de los recursos, etc.

En un artículo del año 1994, Bearman & Sochats definió 6 tipos de metadatos relacionados con:

1) Identificación y descubrimiento de recursos.

2) Condiciones de acceso y de uso necesarias para utilizar un recurso.

3) Aspectos estructurales.

4) Aspectos contextuales.

5) Contenidos.

6) Uso del recurso a lo largo del tiempo.

Esta tipología de metadatos se aplica a la mayoría de los metadatos que podrían ser utilizados tanto para recursos digitalizados como no digitalizados. Hasta ahora, sólo las dos primeras secciones de la tipología de Bearman / Sochats se han desarrollado en cualquier grado.

El tercer grupo de metadatos en la tipología Bearman / Sochats se refiere a la estructura del objeto en sí , los capítulos, secciones, segmentos de datos, etc., que componen la información a la cual estamos asociando los metadatos. El tipo de metadatos asociado aspectos contextuales dan información sobre el contexto en el que el objeto se encuentra, por ejemplo nos da información sobre su origen.

En cuanto a los metadatos de contenido, de acuerdo con Bearman / Sochats, nos ofrecen un análisis mucho más profundo de los aspectos del contexto habitual del objeto que los descriptores de contexto utilizados, tanto para el descubrimiento de recursos como en análisis documentacional. Estos y el último tipo de metadatos en la tipología de Bearman / Sochats aún no han sido tan desarrollado como los dos primeros, probablemente por el hecho de que estos corresponden a un uso más sofisticado de los metadatos que hasta ahora no se ha alcanzado en el entorno de red, aunque existen grupos de trabajo que los están desarrollando en la actualidad.

21

Debemos añadir que los metadatos que se refieren específicamente al objeto en sí, ha tenido también la necesidad de administrar los propios metadatos encontrados por algunos de los ejecutores de los metadatos. Estos metadatos administrativos a nivel local se añaden para distinguir los aspectos de las explotaciones individuales,como suscripciones a la información, los accesos a la información, etc .

Sin embargo a parte de los diferentes tipos de metadatos comentados en el artículo de Bearman/Sochats, podemos indicar otras clasificaciones. Los diferentes modelos de metadatos que se utilizan para codificar la información y que permiten que los Sistemas avanzados de recuperación de información la recuperen pueden clasificarse de muchas formas. Una de las clasificaciones más extendidas es la creada por el Departamento de Preservación y Conservación de la Biblioteca de la Universidad de Cornell. (Tabla 1).

22

TIPO OBJETIVO ELEMENTOS DE MUESTRA IMPLEMENTACIONES DE MUESTRA

Metadatos descriptivos

Descripción e identificación de recursos de información

en el nivel (sistema) local para permitir la búsqueda y la recuperación (por ejemplo, búsqueda de una colección de imágenes para encontrar pinturas con ilustraciones de animales)

en el nivel Web, permite a los usuarios descubrir recursos (por ejemplo, búsqueda en la Web para encontrar colecciones digitalizadas sobre poesía).

identificadores únicos (PURL, Handle)

atributos físicos (medios, condición de las dimensiones)

atributos bibliográficos (título, autor/ creador, idioma, palabras claves)

HandlePURL (Persistent Uniform Resource Locator - Localizador de Recursos Uniforme y Continuo) / Dublin CoreMARCMeta Rótulos HTML (HTML Meta Tags).

vocabularios controlados, como por ejemplo:Tesauro sobre Arte y Arquitectura Categorías para la Descripción de Obras de Arte

Metadatos estructurales

facilitan la navegación y presentación de recursos electrónicos

proporcionan información sobre la estructura interna de los recursos, incluyendo página, sección, capítulo, numeración, índices, y tabla de contenidos

describen la relación entre los materiales (por ejemplo, la fotografía B fue incluida en el manuscrito A)

unen los archivos y los textos relacionados (por ejemplo, el ArchivoA es el formato JPEG de la imagen de archivo del ArchivoB).

rótulos de estructuración como por ejemplo página de título, tabla de contenidos, capítulos, partes, fe de erratas, índice, relación con un sub-objeto (por ejemplo, fotografía de un periódico).

SGML XML Encoded Archival Description, EAD (Descripción de Archivo Codificado) MOA2, Structural Metadata Elements (Elementos de Metadatos Estructurales) Unión Electrónica Electronic Binding, Ebind).

23

TIPO OBJETIVO ELEMENTOS DE MUESTRA IMPLEMENTACIONES DE MUESTRA

Metadatos administrativos

facilitan la gestión y procesamiento de las colecciones digitales tanto a corto como a largo plazo

incluyen datos técnicos sobre la creación y el control de calidad

incluyen gestión de derechos y requisitos de control de acceso y utilización

información sobre acción de preservación.

Datos técnicos tales como tipo y modelo de escáner, resolución, profundidad de bit, espacio de color, formato de archivo, compresión, fuente de luz, propietario, fecha del registro de derecho de autor, limitaciones en cuanto al copiado y distribución, información sobre licencia, actividades de preservación (ciclos de actualización, migración, etc.).

MOA2, Administrative Metadata Elements (Elementos de Metadatos Administrativos) National Library of Australia, Preservation Metadata for Digital Collections (Biblioteca Nacional de Australia, Metadatos de Preservación para Colecciones Digitales).

TABLA 1. Tipos de Metadatos. Biblioteca de la Universidad de Cornell.

1.6. ALGUNAS CRÍTICAS AL USO DE LOS METADATOSAlgunos expertos critican fuertemente el uso de metadatos. Sus argumentos más

sustanciosos son los siguientes:

● Los metadatos son costosos y necesitan demasiado tiempo. Las empresas no van a producir metadatos porque no hay demanda y los usuarios privados no van a invertir tanto tiempo.

● Los metadatos son demasiado complicados. La gente no acepta los estándares porque no los comprende y no quiere aprenderlos.

● Los metadatos dependen del punto de vista y del contexto. No hay dos personas que añadan los mismos metadatos. Además, los mismos datos pueden ser interpretados de manera totalmente diferente, dependiendo del contexto.

● Los metadatos son ilimitados. Es posible adherir más y más metadatos útiles y no hay fin.

● Los metadatos son superfluos. Ya hay buscadores potentes para textos, y en el futuro la técnica query by example («búsqueda basada en un ejemplo») va a mejorarse, tanto para localizar imágenes como para música y vídeo.

Algunos estándares de metadatos están disponibles aunque no se aplican, para los críticos esto es considerado como una prueba más de las carencias del concepto de metadatos. Hay que anotar que este efecto también puede ser causado por insuficiente compatibilidad de los formatos o por la enorme diversidad que amedrenta a las empresas. Fuera de eso hay formatos de metadatos muy populares.

En este proyecto, nos planteamos como objetivo el explicar algunos de los estándares más extendidos de metadatos así como comentar aplicaciones en las que se están utilizando, no sólo con vistas a un futuro cercano, sino dentro del presente más inmediato.

24

CAPÍTULO 2. ESTÁNDARES DE METADATOS MÁS EXTENDIDOS.

1. ESTANDARIZACIÓN E INTEROPERABILIDAD DE LOS METADATOS.

1.1. LA ESTANDARIZACIÓN.La normalización, o estandarización, es la redacción y aprobación de normas que se

establecen para garantizar el acoplamiento de elementos construidos independientemente. Además, garantiza el repuesto en caso de ser necesario, la calidad de los elementos fabricados y la seguridad de funcionamiento. La normalización es un proceso de elaboración, aplicación y mejora de las normas que se aplican a distintas actividades científicas, industriales o económicas con el fin de ordenarlas y mejorarlas. La asociación estadounidense para pruebas de materiales(ASTM), define la normalización como :

“El proceso de formular y aplicar reglas para una aproximación ordenada a una actividad específica para el beneficio y con la cooperación de todos los involucrados”.

Según la ISO (International Organization for Standarization), la normalización es la actividad que tiene por objeto establecer, ante problemas reales o potenciales, disposiciones destinadas a usos comunes y repetidos, con el fin de obtener un nivel de ordenamiento óptimo en un contexto dado, que puede ser tecnológico, político o económico. La normalización persigue tres objetivos fundamentales:

● Simplificación. Se trata de reducir los modelos, quedándose únicamente con los más necesarios.

● Unificación. Para permitir la interoperabilidad a nivel internacional.

● Especificación. Se persigue evitar errores de identificación, creando un lenguaje claro y preciso

Las elevadas sumas de dinero que los países desarrollados invierten en los organismos normalizadores, tanto nacionales como internacionales, es una muestra, más que palpable, de la importancia que se da a la normalización.

En cuanto a los metadatos, podemos decir que parte de los proyectos que existen actualmente sobre metadatos no son en realidad normas, sino proyectos de normas, o estándares que se usan en determinados organismos y grupos de usuarios. Lo cierto es que no existe un modelo internacional de metadatos.

Las únicas normas internacionales en este sentido, son las elaboradas por la ISO/IEC que cuenta con un comité, el Data Management and Interchange JTC1/SC32. Dicho comité se ocupa de normalizar los elementos de datos y facilitar el intercambio de información entre distintas bases de datos. Desde hace unos años, los modelos de metadatos para la descripción de contenidos y documentos han proliferado de forma creciente.

25

Para la descripción de contenidos existen muchos proyectos e iniciativas de normalización, algunas ya muy consolidadas y otras incipientes, pero no existen normas únicas, debido a la dificultad para estructurar y definir el contenido de la World Wide Web. Además de ser una tarea difícil, casi impracticable, puesto que exige distintos niveles de profundidad y distintas formas de categorización según sea el ámbito de actuación donde se apliquen.

De manera similar a la elaboración de documentos impresos, la descripción de un documento web no será la misma para una biblioteca digital especializada que para una biblioteca escolar. A esto se añade que en el caso de los documentos digitales, contamos con documentos elaborados por pequeño comercios on-line, grandes empresas, instituciones, o por personas que fabrican su propia web,pues Internet ha convertido a cualquier persona en editor de documentos.

Cada institución, organismo o sujeto individual estará interesado en un nivel distinto de descripción (más o menos detallado) y en mostrar, sobre todo, determinados datos; una tienda querrá enfatizar el precio; una editorial los derechos de autor; una biblioteca especializada buscará una descripción muy compleja, detallada y bien estructurada, etc.

No es posible satisfacer todas las necesidades a la vez, aunque la necesidad de encontrar en la red precisamente lo que se busca, y no una maraña ingente de información sin sentido, está obligando a tomar medidas concretas para una más correcta y homogénea identificación y descripción de los documentos.

Los intentos de normalizar la descripción de contenidos web, en el campo de la documentación, se centran en dos aspectos principales: el desarrollo de modelos formalizados o estándares de metadatos y los intentos de incorporar los documentos electrónicos a través del campo 856 del formato MARC 21 (además de la adaptación de este formato a la web mediante el desarrollo del MARCXML). El lenguaje XML trabaja con marcas o etiquetas que describen la información, de forma que los usuarios pueden trabajar con esos datos de manera más flexible y comprensible que en el formato MARC. Además, el lenguaje de este esquema de metadatos es comprensible para las máquinas que "leen" la World Wide Web.

De forma más general, una ventaja de cualquier tipo de norma, y de un estándar de metadatos también, es que se establecen a través de un proceso consultivo. proporcionando la base desde la que se desarrollan perfiles a nivel nacional o internacional y orientados a una disciplina o temática particular. Así, si un estándar se acepta dentro de una comunidad amplia, las herramientas informáticas se desarrollarán para la aplicación de esa norma a nivel industrial. Para ello, los metadatos requieren de una consistencia en su contenido y estilo, que aseguren el intercambio de información.

La falta de normas compartidas y la inconsistencia de la indización de la información digital, son los principales obstáculos para un acceso ilimitado y coherente a la información. Los grandes catálogos unificados, en los que las bibliotecas han confiado durante tanto tiempo para compartir e intercambiar registros, proyectos cooperativos, etc., han permitido el acceso a grandes colecciones. Estos accesos simplemente habrían sido imposibles, sino se hubiese empezado la normalización de formatos bibliotecarios en la década de 1960.

En el mundo de la información digital, se usan normas por varios motivos obvios: para incrementar la calidad y la estabilidad de la información, para mejorar la compatibilidad de

26

estructuras de datos y para facilitar tanto la recuperación como el intercambio de información.

Hay dos grupos que impulsan el desarrollo de formatos de metadatos: la técnica multimedia y la web semántica. El destino de la técnica multimedia es describir un singular recurso multimedia, la web semántica pretende obtener unadescripción de recursos de cada tipo y unl encadenamiento de los conocimientos. Algunos de los formatos más populares y extendidos de metadatos son:

● ID3

● MPEG-7

● MPEG-21

● TV-Anytime

● Dublin Core

● LOM

● Marco de descripción de recursos (RDF)

● OWL

● NewsML y SportML

● DVB-IPDC

Algunos de estos estándares se estudiarán a lo largo de este documento, mientras que otros sólo serán comentados de forma breve.

1.2. INTEROPERABILIDAD DE LOS METADATOS.

1.2.1. INTRODUCCIÓN.

En respuesta al rápido desarrollo de las bibliotecas digitales y los repositorios, se han elaborado o propuesto muchos estándares de metadatos, tanto generales como más específicos, por parte de diferentes comunidades de usuarios. Incluso dentro de un mismo dominio o para un mismo tipo de recursos, encontramos a menudo dos o más estándares diferentes en materia de metadatos.

En la construcción de una gran biblioteca digital (o de un repositorio), un problema que con frecuencia nos encontramos, es que los participantes utilizan diversos esquemas de descripción para crear sus registros de metadatos. Idealmente, los usuarios de dicha biblioteca digital o repositorio "deben ser capaces de descubrir, a través de una búsqueda, los objetos digitales de libre acceso en una gran variedad de colecciones, en lugar de tener que buscar en cada colección de forma individual" [Tennant, 2001]. En otras palabras, los usuarios no deberían tener que conocer o comprender los métodos utilizados para describir y representar el contenido de una colección digital.

En la realidad, la diversidad de normas y estándares para la descripción de diversos tipos de recursos multimedia, a veces en la misma biblioteca digital o repositorio, plantea un nuevo

27

reto, tanto para los usuarios como para aquellos que son responsables de la gestión de estos recursos. Sólo si conseguimos desarrollar dispositivos que permitan la interoperabilidad, será posible facilitar el intercambio y la difusión de datos de acuerdo con diferentes esquemas de metadatos, permitiendo la búsqueda de información en colecciones cruzadas.

En la literatura reciente, mucho se ha escrito acerca de lograr la interoperabilidad entre los diferentes esquemas de metadatos. Con este objetivo, se realiza un análisis metodológico de la interoperabilidad en los sistemas de organización del conocimiento (KOS), donde se estudian algunos de los métodos actualmente utilizados para lograr la interoperabilidad en un contexto más amplio, es decir, entre los diferentes esquemas de metadatos y aplicaciones.

1.2.2. ¿QUÉ ES LA INTEROPERABILIDAD?

Ha habido muchos intentos de definir el concepto de interoperabilidad. Aquí mostramos algunos de los ejemplos más utilizados, los cuales nos servirán de guía cada vez que utilicemos el término:

"La interoperabilidad es la capacidad de intercambiar datos con un mínimo de pérdida de contenido y funcionalidad entre múltiples sistemas, con diferentes hardware y plataformas de software, estructuras de datos, e interfaces" [NISO, 2004].

"La interoperabilidad es la capacidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada sin esfuerzo especial" [CC: DA, 2000].

"Interoperabilidad: Es la compatibilidad de dos o más sistemas de manera que puedan intercambiar información y datos y puedan utilizar la información intercambiada y los datos sin ningún tipo de manipulación" [Taylor 2004, p. 369].

Dentro de la comunidad de la información, la interoperabilidad se está convirtiendo en uno de los principios más importantes en la aplicación de los metadatos. Otros principios básicos de los metadatos son la simplicidad, la modularidad, la reutilización y la extensibilidad [Duval et al., 2002; Zeng et al., 2003].

1.2.3. ¿QUÉ ES UN SCHEMA DE METADATOS?

Un esquema (schema) de metadatos consiste en un conjunto de elementos diseñados para un propósito específico, como el de describir un tipo particular de recursos de información [NISO, 2004]. La Asociación Americana de Bibliotecas Comité de Catalogación: Descripción y Acceso (CC: DA), Grupo de Tareas sobre los metadatos dice:

"Un esquema de metadatos proporciona una estructura formal, diseñada para identificar la estructura de conocimiento de una determinada disciplina y para enlazar la estructura de la información de la disciplina a través de la creación de un sistema de información que ayude a la identificación, descubrimiento y utilización de la información dentro de la disciplina".

En la literatura, las palabras "schema", "scheme" y "element set", se han utilizado

28

indistintamente para designar a los estándares de metadatos. En la práctica, la palabra "schema” generalmente se refiere a toda una entidad, incluyendo el contenido semántico, los componentes (que suele ser considerado como un "elemento set"), y la codificación de los elementos con un lenguaje de marcas, como son SGML (Standard Generalized Markup Language) y XML (Extensible Markup Language).

Un conjunto de elementos de metadatos tiene dos componentes básicos:

● Semantics - las definiciones de los significados de los elementos y sus mejoras.

● Content - declaraciones o instrucciones de que nos indican qué valores y cómo se deben asignar a los elementos.

Por lo general, cada elemento definido en un estándar de metadatos proporciona reglas sobre cómo los contenidos deben incluirse (por ejemplo, cómo identificar el título principal), representarse (por ejemplo, la capitalización de reglas o normas de representación del tiempo), o qué valores deben tener (por ejemplo, si los valores deben tomarse a partir de un determinado vocabulario o puede ser suministrado por el autor, derivados del texto, o añadidos por los creadores de metadatos sin una lista de términos de trabajo controlados).

Muchos estándares de metadatos establecen un sets de elementos sin tener en cuenta el formato de codificación de sus versiones preliminares. Por ejemplo, Dublin Core (DC), VRA (Asociación de Recursos Visuales) Core Categories, CDWA (Categories for the Description of Works of Art), y el LOM (Learning Object Metadata). Todos son estándares de metadatos publicados y aceptados, en cuanto a su contenido y a la semántica, mucho antes de que la codificación de métodos específicos para sus modelos de datos fuera publicada.

Por otro lado, algunos estándares de metadatos, como el Encoded Archival Descriptor Document Type Definition (EAD DTD), presentan un conjunto elementos codificados desde el principio. El EAD DTD es un estándar para la codificación de archivos de ayuda en las búsquedas que actualmente utilizan XML, se publicó hace una década con un SGML DTD [Biblioteca del Congreso,2003].

Para nosotros, el término "schema" se utilizará para referirse a todos los estándares de metadatos, aunque la mayoría de la veces el término se centrará en la semántica y el contenido, como hemos venido hablando con anterioridad.

1.2.4. INTEROPERABILIDAD DE METADATOS A DIFERENTES NIVELES.

En los últimos años numerosos proyectos se han llevado a cabo por parte de los diferentes actores y partes interesadas en la comunidad de la información, para lograr la interoperabilidad entre los distintos esquemas de metadatos y sus aplicaciones.

Lo ideal sería que un estándar uniforme garantizara la máxima interoperabilidad entre las colecciones de recursos. Si todos los participantes de un consorcio o repositorio estuvieran obligados a utilizar el mismo esquema, como el MARC (Machine-Catalogación de lectura) o el formato Dublin Core (DC), se mantendría un alto nivel de coherencia. Éste, por supuesto, ha sido el enfoque que la comunidad bibliotecaria ha mantenido desde hace más de un siglo, y sería la solución definitiva al problema de la interoperabilidad.

29

Sin embargo, a pesar de que conceptualmente es una solución sencilla, no siempre es factible ni práctica. El problema se acentúa más en entornos heterogéneos al servicio de diferentes comunidades de usuarios o donde las colecciones de componentes que participan contienen diferentes tipos de recursos, que ya están descritos por una gran variedad de schemas especializados.

El método uniforme de normalización sólo es viable al comienzo o en las primeras etapas de la construcción de un repositorio, antes de que los distintos schemas sean adoptados por los participantes. Los ejemplos incluyen los estándares: MARC, utilizado en catálogos de las colecciones de las bibliotecas y Dublin Core, basado en electrónica de tesis y disertaciones estándar de metadatos (ETD-MS) y utilizado por los miembros de la Red de Bibliotecas Digitales de Tesis y Disertaciones (NDLTD).

En muchas situaciones y comunidades la utilización de un único estándar uniforme simplemente no puede ser aplicada. Esto hace que se deba tener en cuenta la interoperabilidad entre estándares de metadatos. Desde un punto de vista metodológico, la aplicación de la interoperabilidad puede llevarse a cabo en diferentes niveles: a nivel de schema, a nivel de registro o a nivel de repositorio. (Figura 1).

Figura 1. Varios niveles de proyectos de metadatos.

La figura 1 tiene como objetivo explicar las posibles trayectorias de creación de schemas de metadatos para aplicaciones, tanto en proyectos individuales como en proyectos integrados en los repositorios. Las distintas situaciones pueden ser:

● Schema creado y aplicado a los registros de uno o más proyectos.

● Elementos de varios schemas son tenidos en cuenta. El perfil de una aplicación se establece sobre la base de una serie de schemas; a continuación, el set de elementos especificados por el perfil de la aplicación se aplica a los registros de uno o varios

30

proyectos determinados.

● Dos o más bases de datos con registros de metadatos son intercambiadas o integradas, basándose en la asociación de los elementos de los schemas que participan.

● Registros de las colecciones de metadatos existentes son recopilados y fusionados en un único repositorio. En estas colecciones se han aplicado diferentes schemas o se han establecido sus propios perfiles de aplicación antes de ser utilizadas.

Desde otra perspectiva, los resultados de los esfuerzos de interoperabilidad pueden observarse en diferentes niveles:

1. Nivel de Schema. Los esfuerzos se centran en conseguir que los elementos de los schemas sean independientes de cualquier aplicación. Los resultados suelen aparecer como derivados de sets de elementos o conjuntos de schemas codificados, crosswalk, perfiles de aplicación, y los registros elementos.

2. Nivel de Registro. Los esfuerzos están destinados a integrar los registros de metadatos a través del mapeo de los elementos, de acuerdo con el significado semántico de estos elementos. Los resultados incluyen registros convertidos y nuevos registros resultantes de la combinación de los valores de registros ya existentes.

3. Nivel de Repositorio. Con registros recopilados e integrados de diferentes fuentes, los esfuerzos en este nivel se centran en el mapeo de cadenas asociadas a elementos particulares (por ejemplo, términos asociados con el objeto o formato de los elementos).

Cabe señalar que los modelos de los cuales estamos hablando no siempre son excluyentes entre si. A veces, dentro de un proyecto en particular, más de un método puede ser utilizado.

Nosotros vamos a centrarnos en explicar con mayor detalle de qué trata la interoperabilidad entre distintos schemas de metadatos. Para ello, vamos a explicar, más adelante, los estándares de metadatos utilizados en el desarrollo de una plataforma de servicios horizontal en DVB-H. Estándares, como MPEG-7,TVA, DVB-IPDC y XML, en los que para mantener la interoperabilidad de los metadatos deberemos aportar los distintos schemas de cada uno de dichos estándares.

1.3. INTEROPERABILIDAD EN EL NIVEL DE SCHEMA.Antes de que en un proyecto se seleccione y se aplique un determinado schema de

metadatos a su colección, debemos tener en cuenta un paso importante. Debemos asegurarnos que los datos procesados, de acuerdo a un determinado schema, darán lugar a una colección digital que es interoperable con otras colecciones digitales.

En el nivel de schema, las acciones de interoperabilidad suelen tener lugar antes de nivel operativo de los registros de metadatos sean creados. Estas acciones se centran en los elementos, independiente de aplicaciones individuales.

Los métodos utilizados para lograr la interoperabilidad en esta etapa incluyen principalmente: derivación, perfiles de aplicación, crosswalk, switching-across, framework, y

31

registros. Vamos a realizar un análisis cualitativo de cada uno de estos métodos.

1.3.1. DERIVACIÓN.

En este método un nuevo schema deriva de un schema ya existente. En una colección de bases de datos digitales donde los distintos componentes tienen diferentes necesidades y requisitos en cuanto a descripción de detalles. La existencia de un schema complejo, como el formato MARC, puede utilizarse como "fuente" o "modelo" de nuevos y más simples schemas. Métodos específicos de derivación incluyen la adaptación, modificación, ampliación, adaptación parcial, traducción, etc. del schema matriz o fuente. De esta manera, el nuevo schema creado dependerá del schema matriz.

Este enfoque asegura una estructura básica similar entre schemas, así como la existencia de elementos comunes. Al mismo tiempo, permite que diferentes componentes varíen en profundidad y detalles. Por ejemplo, el TEI Lite deriva del estándar completo Text Encode Inititative (TEI). Otro ejemplo lo encontramos en los estándares Mods (Object Metadata Descripción Schema) y MARC Lite, ambos derivan del estándar completo MARC 21. Los cambios también pueden ocurrir en el formato de la codificación (por ejemplo, MARCXML), o en el contenido original de los elementos básicos. (Figura 2).

Un enfoque similar a la derivación, es la traducción de un esquema existente en un idioma diferente. El contenido sigue siendo en gran parte el mismo que el del schema matriz. Encontramos ejemplos donde se incluyen diferentes versiones lingüísticas del sets de elementos del Dublin Core.

Figura2. Ejemplos de derivación de schemas.

Otra variación es la adaptación de un esquema existente mediante modificaciones que pretenden atender necesidades locales o específicas. Este planteamiento refleja el principio de extensibilidad de los metadatos. Los sistemas de metadatos extensibles deben permitir ampliaciones y expansiones, de forma que las necesidades particulares de una aplicación dada puedan ser atendidas. Ejemplos de adaptación / modificación:

● Elementos propuestos por el Dublin Core Metadata Element Set, para las aplicaciones y proyectos relacionados con la educación y la formación. El último documento de trabajo añade un elemento de audiencia [Condiciones de metadatos DCMI].

● Electronic Theses and Dissertations Metadata Standard (ETD-MS). Este estándar utiliza 13 de los 15 elementos de Dublin Core y un elemento adicional: thesis.degree [ETD-MS].

32

● El portal de Materiales Educativos (Gateway to Educational Materials,GEM), es una ampliación de Dublin Core que incluye elementos adicionales como: la catalogación, los recursos esenciales, la pedagogía, las normas, y la duración [GEM Elemento Conjunto].

● Rare Materials Descriptive Metadata, elaborado por la Biblioteca de la Universidad de Pekín. Utiliza 12 elementos de DC, además de edition y physical description como dos elementos básicos, y un elemento collection history para la extensión de tercer nivel.

1.3.2. PÉRFILES DE APLICACIÓN

Incluso dentro de una comunidad de información hay diferentes necesidades por parte de los usuarios. Los datos facilitados por un schema no siempre pueden satisfacer las necesidades de todos los grupos de usuarios.

Por ello, y sobre la base de que los estándares de metadatos están diseñados y optimizados para unos determinados contenidos específicos, se crea el concepto de “perfil de aplicación”. Este concepto está basado en la noción de que los estándares de metadatos tienen como objetivo describir un conjunto determinado de contenidos [Johnston, 2003].

Mientras la existencia de un schema (o de un conjunto de schemas) se utiliza como base para la descripción de una biblioteca digital o repositorio, las necesidades individuales se cumplen a través de un conjunto de directrices de aplicación específicas establecidas para un interés particular o para un grupo de usuarios.

De acuerdo con la Iniciativa de Metadatos Dublin Core (DCMI), "un perfil de aplicación (AP) es una declaración de metadatos que una organización, recurso de información, aplicación, o comunidad de usuarios utiliza".

El uso de perfiles de aplicación asegura una estructura básica similar, y elementos comunes, permitiendo al mismo tiempo diferentes grados de profundidad y detalle para distintas comunidades de usuarios.

33

Figura 3. Ejemplo de un “Perfil de Aplicación” consistente de metadatos procedentes de uno o más namespaces (sets de elementos)

Los perfiles de aplicación, por lo general, consisten en elementos de metadatos procedentes de uno o más schemas de metadatos (véase la figura 3) combinados en un schema compuesto por implementadores y optimizado para una aplicación local. Por ejemplo, la Biblioteca Virtual de Ingeniería de Australasia, la AVEL, se compone de un conjunto de metadatos de diecinueve elementos. Además de prestar apoyo a 14 elementos DC (con exclusión del elemento dc.source), también apoya: al AGLS (Servicio Localizador del Gobierno de Australia) elemento de metadatos (AGLS.Availability), al Edna (Red de Educación Australia) con el elemento (EdNA.Review), y tres elementos administrativos (AC.Creator, AC.DateCreated, y AVEL.Comments).

Un perfil de aplicación (AP) también puede basarse en un único schema, pero adaptados a diferentes comunidades de usuarios. Por ejemplo, el Perfil de Aplicación DC-Biblioteca (DC-Lib) clarifica el uso del set de metadatos DC en bibliotecas relacionadas con aplicaciones y proyectos. El DC Government Application Profile clarifica el uso de DC en un contexto gubernamental .

Otro ejemplo es el perfil de datos biológicos de la National Biological Information Infrastructure (NBII). Se basa en el Estándar de Contenido para Metadatos Geoespaciales Digitales (CSDGM) del Comité Federal de Datos Geográficos (FGDC).

Existe una cosa que no está muy clara en los implementadores AP (application profile): ¿Puede un AP declarar nuevos términos de metadatos (elementos y mejoras) y definiciones? La respuesta es que, por definición, un AP no puede "declarar" metadatos nuevos, términos o definiciones.

Heery y Patel (2000) destacó las características de los perfiles de aplicación: podrán recurrir a uno o más namespaces, no podrán introducir nuevos elementos de datos, podrán especificar los schemas y valores autorizados y podrán mejorar las definiciones de estándares ya establecidos. Ellos comentaron además que, "en caso de que un implementador AP desee crear elementos que no existen entonces (en virtud de este modelo) se debe crear su propio schema de nombres, y asumir la responsabilidad de la 'declaración' y el mantenimiento del schema".

34

Dublin Core Application Profile Guidelines incluyen también instrucciones sobre "la identificación de términos con la precisión adecuada" (artículo 3) y "la declaración de nuevos elementos" (Sección 5.7). Un AP también puede proporcionar documentación adicional acerca de cómo los términos empleados se ven limitados, codificados, o sobre cómo deben interpretarse para fines particulares.

En la práctica, entonces, la implementación de un perfil de aplicación (AP), implica a menudo implica los siguientes pasos:

(1) La selección de un namespace de metadatos.

(2) La selección de metadatos de otros namespaces.

(3) La definición de elementos de metadatos locales y la declaración de nuevos elementos namespaces.

(4) Hacer cumplir la utilización de los elementos seleccionado y definidos en los pasos anteriormente descritos (incluidos los encargados de hacer cumplir la cardinalidad, el valor de restricción de espacio, y las especificación de relación y dependencia).

Según la Oficina de Bibliotecas y Redes de Información del Reino Unido (UKOLN), un registro de perfiles de aplicación (APR) contiene varios sets de metadatos, así como un gran número de informes de actividad que describen y comentan dichos sets de metadatos, relacionados con diferentes actividades e iniciativas.

1.3.3. CROSSWALKS

Un cosswalks (Figura 4) es "un mapeo de los elementos, atendiendo a la semántica y la sintaxis, de un sistema de metadatos a otro sistema distinto" [NISO, 2004]. Actualmente, los crosswalks son, con mucho, los métodos más utilizados para permitir la interoperabilidad entre los distintos schemas de metadatos.

Este método se inicia con schemas de metadatos independientes donde se hacen intentos para crear el mapeo de correspondencias entre metadatos equivalentes o comparables de los distintos schemas. Hay que tener en cuenta que existen más de un término para referirse a un elemento de un schema de metadatos, como por ejemplo,"campo", "etiqueta", "tag", etc. El mecanismo utilizado en los cruces o crosswalks, por lo general es un gráfico o tabla que representa la semántica del mapeo entre los elementos de un estándar de datos (fuente) y de los que están en el otro nivel (objetivo). Dicho mapeo, se basa en la similitud de funciones entre los metadatos o el significado de los elementos [Baca et al., 2000].

35

Figura 4. Establecimiento de un crosswalk entre dos schemas de metadatos.

Utilizando un sistema crosswalks de manera efectiva, podemos convertir los datos de un estándar de metadatos a otro. Los crosswalks nos permiten realizar búsquedas simultáneas en colecciones heterogéneas, como si se trataran de una única base de datos (permiten interoperabilidad semántica).

En los últimos años, importantes esfuerzos en el mapeo de metadatos han permitido generar un gran número de crosswalk, de manera que casi todos los schemas de metadatos cuentan hoy con un crosswalks a los schemas más populares (DC, MARC, LOM, etc.). Existe también la posibilidad de que estándares de metadatos ya definidos puedan incluir los crosswalks necesarios a una versión anterior del schema, así como a otros schemas de metadatos. Un ejemplo de ello es la VRA Core 3.0, que mapea los elementos del schema de VRA 2.0 (una versión anterior), CDWA, y DC.

El principal método utilizado en crosswalking es el mapeo directo o establecimiento de

equivalencias entre los elementos de diferentes schemas. El “mapeo de metadatos” se refiere a una identificación oficial, o equivalente, de metadatos, o grupos de elementos de metadatos de diferentes schemas de metadatos, y se lleva a cabo con el fin de facilitar la interoperabilidad semántica.

Existen muchas propiedades de los metadatos que deben ser tenidas en consideración en el mapeo de metadatos. Según el documento Issues in Crosswalking Content Metadata Standards [St. Pierre and LaPlant, 1998], las propiedades comunes que se pueden incluir son:

● Una definición semántica de cada elemento de metadatos.

● Si un elemento de metadato es o no obligatorio o facultativo bajo determinadas condiciones.

● Si un elemento de metadatos puede aparecer varias veces en el mismo registro.

● Limitaciones debidas a la organización de los elementos de metadatos en relación con los demás, por ejemplo, relaciones jerárquica entre padres e hijos.

● Las limitaciones impuestas por el valor de un elemento (por ejemplo, texto libre, rango numérico, fecha, o un vocabulario controlado), y soporte opcional para elementos de metadatos definidos localmente.

Dos enfoques de crosswalking se han utilizado en la práctica. El "crosswlking

36

absoluto", enfoque que requiere de un mapeo exacto entre los elementos implicados (por ejemplo, vra.title → dc.title) entre un schema fuente (por ejemplo, VRA Core) y un schema objetivo (por ejemplo, DC). En caso de que no exista una equivalencia exacta, no hay crosswalking (por ejemplo, vra.technique → [espacio vacío]) (vea la Figura 5).

El crosswalking absoluto garantiza la equivalencia de elementos, pero no funciona bien para la conversión de datos. El problema es que los valores de los datos de un espacio, no serán mapeables si tienen una estructura mucho más rica que la del schema objetivo.

Para superar este problema, se utiliza un enfoque alternativo, el "crosswalking relativo". Este es utilizado para mapear todos los elementos en un schema fuente a por lo menos un elemento de un schema objetivo. Es un método

independientemente de si los dos elementos son semánticamente equivalentes o no (por ejemplo, VRA . dc.format técnica →) (también vea la Figura 5). El enfoque crosswalking relativo parece funcionar mejor cuando se mapea de un schema complejo a un schema más simple (por ejemplo, desde DC a MARC, pero no viceversa).

Figura 5. Crosswalking relativo y absoluto.

Uno de los problemas del crosswalking es la existencia de diferentes grados de equivalencia: uno a uno, uno-a-muchos, muchos-a-uno, y uno-a-ninguno. Estas situaciones se producen en muchos cruces de metadatos. El nivel de detalle puede ser utilizado para el mapeo entre un elemento y varios elementos o sub-elementos. Sin embargo, generalmente sólo los nombres de los elementos y sus definiciones se toman en consideración a la hora de realizar un cruce o crosswalks de metadatos.

Figura 6. Diferentes grados de equivalencia entre elementos que han sufrido un crosswalks entre dos schemas distintos. A1 y B1 representan elementos de los schemas A y B.

37

Esto significa que, con frecuencia cuando mapeamos elementos individuales no hay equivalentes exactas. Mientras tanto, muchos de los elementos se encuentran superpuestos en cuanto a significado y alcance se refiere. Por esta razón, la conversión de datos basado en los crosswalks podría crear ciertos problemas de calidad. Esta cuestión se volverá a tratar más adelante en la sección de Registros de Metadatos.

1.3.4. SWITCHING-ACROSS

Aunque el crosswalking funciona bien cuando el número de schemas que intervienen es pequeño, el mapeo entre múltiples schemas no sólo es una labor extremadamente tediosa e intensiva, sino también requiere de un enorme esfuerzo intelectual. Por ejemplo, un crosswalks en una única dirección requiere de un proceso de mapeo (A → B), pero si queremos que hay un crosswalks de doble sentido, el cruce requiere de dos procesos de mapeo, (A → B y B → A).

El proceso se vuelve más engorroso cuanto mayor es el número de schemas involucrados. Un schema con cuatro cruces o crosswalks requeriría de doce (seis pares) procesos de mapeo. Como resultado de ello, el uso de la conmutación de schemas (nuevos o existentes) para canalizar crosswalking entre varios schemas se ha convertido en una solución muy aceptada. A este proceso se le conoce como “Switching-across” de schemas de metadatos (ver Figura 7).

Figura 7. Utilización de Switching-across cuando tenemos múltiples schemas involucrados.

En este modelo, uno de los schemas es utilizado como mecanismo de conmutación entre el resto de schemas. En lugar de utilizar un mapeo entre cada par de schemas del grupo, cada uno de los schemas de metadatos es mapeado al schema switching únicamente. Un ejemplo de ello es el crosswalks de Getty, donde 7 schemas son mapeados al schema de CDWA.

38

Figura 8. Crosswalk de CDWA a siete schemas diferentes.

1.3.5. FRAMEWORK DE METADATOS

Un framework puede ser considerado como un esqueleto sobre el que diversos objetos se integran para obtener una determinada solución (ver Figura 9). La necesidad de un framework de metadatos es la mejor demostración de los nuevos esfuerzos que se dan para la preservación digital.

Aunque muchas organizaciones han desarrollado metadatos para la preservación digital en apoyo de sus propias actividades, tales esfuerzos se han llevado a cabo en gran medida de forma aislada, carente de cualquier grado sustancial de cooperación transfronteriza o coordinación entre organizaciones.

Se hace evidente la necesidad de un framework de metadatos que represente un consenso de los principales expertos y profesionales, que pueda ser fácilmente aplicado a una amplia gama de actividades. En 2002, un framework conceptual para sistema de archivado digital surgió en la forma de un modelo de referencia conocido como el Open Archival Information System (OAIS). Se publicó como una recomendación del Comité Consultivo para el Espacio de Sistemas de Datos de la ISO (CCSDS), que establece un marco común para los términos y conceptos que componen un Sistema Abierto de Archivos de Información (Open Archival Information System), proporcionando una base para una mayor estandarización dentro del

39

contexto de un archivo.

Figura 9. Schemas asociados a un framework.

Otro ejemplo lo encontramos en el framework de metadatos que actualmente se utilizan en la DLESE (Digital Library for Earth System Education) Discovery System. Después de una serie de años de estudios, con el objeto de establecer un framework DLESE para metadatos basados IMS (Instructional Management Systems), el proyecto Alexandria Digital Earth Prototype (ADEPT) , DLESE, y el Joined Digital Library (JDL) de la NASA, decidieron en Junio de 2001 crear un framework de metadatos que las tres organizaciones puedieran usar, lo denominaron “framework Y” .

El propósito del framework Y, como se indica en su página web, es "describir los recursos que se suelen utilizar en entornos de aprendizaje (por ejemplo, las actividades de un aula, planes de estudios, módulos, visualizaciones, algunos conjuntos de datos o datasets) para el descubrimiento de un sistema global para comunidad educativa terrestre. El contenido de la información que encontramos en un registro de metadatos incluye las siguientes categorías de elementos, entre los cuales la Educación, Espacio y Tiempo tienen valores únicos:

● General (título, idioma, palabras clave, temas, descripción).

● Educación (por ejemplo, tipo de recurso, rango de grados).

● Espacio y Tiempo.

● Relaciones (la conexión de recursos a los demás).

● Derechos (de recursos y el costo de derecho de autor).

● Técnico (URL, navegador, plataforma, plug-ins).

● Recursos y catalogadores de recursos creadores.

● Los datos administrativos (número de identificación, los metadatos de derechos de autor).

Los ejemplos, citados más arriba, muestran los enfoques que son posibles para la construcción de un framework de metadatos:

1. El establecimiento de un framework antes del desarrollo individual de los distintos schemas y aplicaciones.

40

2. La construcción de un framework basado en los actuales schemas.

Independientemente del método que se utiliza, la función de un framework de metadatos es proporcionar un entorno adecuado para las diversos usuarios de las comunidades involucradas.

1.3.6. REGISTRO DE METADATOS

La finalidad de un registro de metadatos es bastante sencilla: recoger datos acerca de de diferentes schemas de metadatos. Debido a que la reutilización de metadatos existentes es esencial para lograr la interoperabilidad entre los elementos de diversos conjuntos de metadatos, la identificación de los términos existentes llega a ser un requisito previo en un nuevo proceso de desarrollo de schemas de metadatos. Así pues, la presencia de un registro de metadatos promueve la más amplia adopción, estándarización e interoperabilidad de los metadatos, así como facilita su descubrimiento y la reutilización a través de diversas disciplinas y comunidades.

Los registros de metadatos son utilizados para proporcionar los medios para identificar y establecer las referencias entre los schemas establecidos y los perfiles de aplicación. Potencialmente, pueden incluir los medios para crear una máquina de mapeo entre los diferentes esquemas. Además, se espera que estos registros incluyan, o enlacen, con importantes vocabularios controlados, a partir de los cuales podamos seleccionar los valores de los campos de los metadatos.

Las funciones preliminares de los registros de metadatos incluyen el registro, publicación y gestión de schemas y perfiles de aplicación, así como hacer búsquedas en ellos. Un registro también proporciona servicios de crosslinking y crosswalking entre los schemas y perfiles de aplicación (véase figura 10).

Figura 10. Un registro de metadatos relacionado con varios schemas.

Los componentes básicos de un registro de metadatos deben permitir la identificación de modelos de datos, elementos, de elemento conjuntos, de esquemas de codificación, perfiles de

41

aplicación, información del uso de un elemento, de elementos usados en crosswalks. A pesar de estos componentes comunes cada registro tiene un ámbito específico de aplicación.

Los siguientes ejemplos representan cuatro diferentes gamas de registro:

1. Registros Cross-Domine y Cross-Schemas. Por ejemplo, el UKOLN (UK Office for Library Networking) Schemas Registry, que ahora se usa en el nuevo proyecto CORES, contiene varios conjuntos de elementos de metadatos y documentos relacionados. A través de una interfaz web, se puede buscar o navegar en función de los organismos, elemento conjuntos, elementos, esquemas de codificación, perfiles de aplicación, usos y elementos que se incluyen en este registro. En la actualidad, el registro consta de 12 conjuntos de elementos de 10 instituciones distintas [CORES].

2. Registro Domain-Specific y Cross-Schemas. Por ejemplo, el UKLON del MEG (Metadatas for Education Group), que facilita el registro de schemas dentro del dominio educativo [MEG Registro].

3. Registro Project-Specific. El registro de metadatos del The European Library (TEL) se creó con el fin de recoger todos los metadatos asociados con las actividades TEL. El registro incluye las traducciones de nombres de elementos de metadatos en diferentes idiomas y declara si el elemento es: repetible, localizables u obligatorio.

4. Registro Schema-Specific, como el registro de la Iniciativa de Metadatos Dublin Core (DCMI) o Registro de Datos Open (Dublin Core Metadata Registro), para registrar la validez de elementos dentro del esquema DC. En la actualidad, el registro proporciona detalles sobre los elementos, el elemento más detallados, los términos del vocabulario controlado (DCMI-Type Voc.), así como la codificación de los schemas y propio vocabulario usado.

Como Duval et al. (2002) señaló; “la importancia de la gestión y divulgación de las funciones de los registros se incrementará a medida que más metadatos y schemas con perfiles de aplicación se vayan desarrollando”.

2. EL ESTÁNDAR ID3

2.1. INTRODUCCIÓNEl estándar ID3 es un estándar de facto, de forma que aunque no está adoptado por

ningún organismo de estandarización es uno de los más aceptados y utilizados. ID3 se utiliza para poder introducir etiquetas en contenedores multimedia, etiquetas como título,álbum o artista. El estándar ID3 se encuentra asociado al formato de codificación más extendido dentro del sector de los reproductores de audio, el formato MP3 (MPEG-1 Audio Layer 3).

El hecho de que hagamos una breve reseña del estándar ID3 se debe a la enorme cantidad de usuarios de música en MP3 existente en el mundo. Cualquiera de nosotros tenemos o hemos tenido un reproductor de música MP3, de modo que el uso de ID3 se puede considerar un buen ejemplo de como los metadatos se encuentran en nuestra vida cotidiana, aunque no

42

seamos conscientes de ello.

El formato de música MP3 ha llegado tener tal importancia que ha hecho renacer a una de las empresas más importantes y “archifamosas” en el sector tecnológico, la empresa Apple. Ésta, tras el lanzamiento de su reproductor MP3, “iPod”, se ha visto encumbrada a la cima de las empresas tecnológicas más importantes y poderosas del sector.

Volviendo al estándar de metadatos, decimos que las etiquetas ID3 surgen con posterioridad al estándar MP3. La necesidad de catalogar los ficheros de sonido con información textual básica de su procedencia: autor, título, etc., Eric Kemp (alias NamkraD), aprovechando el desarrollo del programa "Studio3", introdujo una solución a este problema en 1996. Así, sugirió la posibilidad de incluir dichos metadatos al final de cada fichero MP3.

Finalmente, esta idea fue implementada con gran éxito entre los usuarios, naciendo la primera versión de ID3. Michael Mutschler, creador de MP3ext, sugirió la versión 1.1 de ID3. A pesar de su éxito existían quejas sobre algunas limitaciones técnicas del formato de las etiquetas. Por ello, se elaboró la versión 2 de este estándar informal.

El etiquetado de ficheros multimedia es imprescindible para su catalogación. La clasificación mediante carpetas y nombres de fichero es insuficiente para grandes colecciones ya que solamente facilita un único criterio de búsqueda. Mediante el etiquetado es posible organizar una colección mediante múltiples criterios. Permite una búsqueda más rápida y sencilla de aquellos archivos que se desean.

Las especificaciones de ID3 son aplicables a cualquier fichero o contenedor multimedia, aunque se suele aplicar principalmente a contenedores de audio. Existen tres versiones de la especificación que son compatibles entre sí (v1.0, v1.1 y v2.0). Por ejemplo, un fichero puede contener simultáneamente etiquetas de la versión 1.1 y de la versión 2.0. En este caso, el reproductor multimedia debe decidir cuales son relevantes.

2.1. ID3 VERSIÓN 1Esta primera especificación es muy simple. Consiste en adjuntar un bloque de tamaño

fijo de 128 bytes al final del fichero en cuestión. Este bloque contiene las siguientes etiquetas:

● Una cabecera que identifica la presencia del bloque ID3 y su versión. En concreto, dicha cabecera consta de los caracteres TAG.

● Título: 30 caracteres.

● Artista: 30 caracteres.

● Álbum: 30 caracteres.

● Año: 4 caracteres.

● Un comentario: 30 caracteres.

● Género (musical): un carácter.

Todas las etiquetas usan caracteres ASCII, excepto el género, que es un número entero almacenado en un único byte. El género musical asociado a cada byte está predefinido en

43

el estándar e incluye definiciones de 80 géneros, numerados del 0 al 79. Determinados programas de reproducción han ampliado por su cuenta los géneros definidos (a partir del número 80).

Un inconveniente de la versión anterior es que no es posible indicar el número de pista correspondiente al álbum al que pertenece la grabación. La versión 1.1 simplemente "resta" los dos últimos caracteres de la etiqueta comentario para este propósito. Para distinguir esta versión de la anterior, el carácter nº 29 debe ser obligatoriamente un carácter nulo seguido de un número entero en formato byte que almacena el número de canción en el álbum. Si el carácter nº 30 es nulo o si el nº 29 no lo es, el número de canción se presupone no especificado.

Se trata de una solución sencilla y compatible con la versión anterior. Esto incluye la compatibilidad del software.

2.2. ID3 VERSIÓN 2Aunque ID3 versión 1 es más que suficiente en muchos de los casos pero es una

versión que presente presenta algunos problemas serios, tales como:

● La longitud de las etiquetas es insuficiente para algunas grabaciones.

● El uso de caracteres ASCII impide su uso con lenguas no occidentales.

● El conjunto de etiquetas es insuficiente. Por ejemplo, en algunas grabaciones es necesario distinguir el autor del intérprete, e ID3 no te lo permite.

● No es posible incluir nuevas etiquetas no predefinidas, en función de las necesidades de cada usuario. Por ejemplo, las preferencias de ecualización.

Por estos motivos surge la versión 2 de ID3. Los detalles técnicos son más complejos que en las versiones anteriores. Las diferencias más significativas son:

● Utiliza caracteres Unicode, por lo que está abierto a cualquier lengua.

● Las etiquetas se sitúan al principio del fichero, no al final. Esto facilita la difusión por Internet mediante streaming, ya que no hay que esperar a que se descargue todo el fichero para conocer las etiquetas.

● Las etiquetas pueden tener mayor o menor longitud. No hay restricciones.

● Es posible incluir imágenes, no solo texto. Por ejemplo, la carátula del álbum.

● Admite etiquetas definidas por el usuario.

● Se han predefinido más de 35 etiquetas estándar.

● La letra de la canción se puede almacenar bajo el frame Lyrics3 en la TagID3, al igual que la portada del álbum.

● Las etiquetas pueden ser cifradas.

44

3. EL ESTÁNDAR DUBLIN CORE

3.1. INTRODUCCIÓNLa Iniciativa Dublin Core (DCMI) (http://dublincore.org) comenzó su andadura en 1995

durante un encuentro en Dublin, Ohio (USA), en el que participaron más de 50 personas. En esta reunión se discutió de cómo un conjunto de recursos semánticos podrían ser muy útiles para facilitar la búsqueda y la recuperación de información heterogénea en la web. En este evento conocido como "Taller de Metadatos OCLC/NCSA" , se encontraron representantes del NCSA (National Center for Supercomputing Applications) y OCLC (On Line Library Computer Center), junto con otros de la IETF (Internet Engineering Task Force).

Bibliotecarios, proveedores de contenido y expertos en lenguajes de marcado, pretendieron desarrollar estándares para describir los recursos de información y facilitar su recuperación. Así nació un pequeño conjunto de descriptores, en principio pensados para que fuera el propio autor el que los incluyera en el documento o recurso, pero que rápidamente adquirieron alcance global. Se interesaron en ellos numerosos y variados proveedores de información pertenecientes a diferentes sectores como el de las artes, las ciencias, la educación, los negocios y la administración. Desde marzo de 1995 se han formado un total de ocho talleres o grupos de trabajo en países tan distantes como Inglaterra, Australia, Finlandia, Alemania, Canadá y los Estados Unidos.

Hoy, los metadatos Dublin Core se han convertido en uno de los estándares más extendidos para la recuperación de información en la World Wide Web, convirtiéndose en un vocabulario muy utilizado no sólo en el ámbito bibliotecario y documental, sino en otros muchos sectores. Además, este conjunto de metadatos se puede utilizar no sólo con HTML sino sobre otros lenguajes estructurados como XML, conjuntamente con otros lenguajes de descripción como RDF. El set de metadatos Dublin Core se convirtió en norma ISO (ISO 15836-2003) en febrero de 2003.

En España, ha sido principalmente la “RedIris” la que, casi en solitario, comenzó a trabajar con los metadatos Dublin Core a través del grupo denominado iris-index (http://www.rediris.es/metadata). Este grupo gestiona la lista de distribución DCMI-ES (foro español del Dublin Core Metadata Initiative), aunque en el año 2001 se creó un grupo de trabajo sobre normalización para la recuperación de información en Internet en el marco de SEDIC (Sociedad Española de Documentación e Información Científica), uno de cuyos temas de interés es, precisamente, los metadatos Dublin Core.

3.2. CARACTERÍSITICAS Y OBJETIVOS DE DUBLIN COREAlgunas de las principales características de Dublin Core las presentamos en los

siguientes puntos:

● Simplicidad. El uso de DC reduce considerablemente los costos y promueve la interoperatividad. La simplicidad no significa acomodar o desechar la semántica y las funciones enriquecidas, soportadas por otros sistemas complejos de metadatos: Dublín

45

Core estimula el uso de formatos de metadatos enriquecidos en combinación y a menudo es también el punto de partida para la creación de descripciones más complejas.

● Interoperatividad semántica. Establece vínculos y relaciones con otras normas, sin sacrificar su autonomía.

● Consenso internacional. Dublín Core se ha convertido en una parte importante de la infraestructura de Internet y su uso se ha extendido a escala internacional.

● Extensibilidad. Propiedad que deriva, en parte, de la flexibilidad y en parte de la definición de elementos estructurados con distintos grados de complejidad y requerimientos. También se relaciona con su capacidad de convertirse fácilmente a otros formatos, entre ellos y a pesar de su complejidad, al propio formato MARC.

● Flexibilidad. Nada en Dublín Core es obligatorio, todos los elementos son opcionales y repetibles, así el usuario elige la profundidad de su descripción. El formato además, permite incorporar desde estructuras simples hasta aquellas más elaboradas semánticamente.

La Dublin Core Metadata Initiative (DCMI) es la responsable del desarrollo, estandarización y promoción del conjunto de los elementos de metadatos Dublin Core. Su objetivo es elaborar normas inter-operables sobre metadatos y desarrollar vocabularios especializados en metadatos para la descripción de recursos, que permitan sistemas de recuperación más inteligentes. En concreto, la iniciativa pretende:

● Desarrollar estándares de metadatos para la recuperación de información en Internet a través de distintos dominios

● Definir el marco para la interoperabilidad entre conjuntos de metadatos.

● Facilitar el desarrollo de conjuntos de metadatos específicos de una disciplina o comunidad que trabaja dentro del marco de la recuperación de información.

Para lograr alcanzar dichos objetivos, la comunidad de Dublin Core está centrando sus esfuerzos en:desarrollando los siguientes temas :

● Desarrollar metadatos Dublin Core en formato XML,RDF/XML etc.

● Crear distintos perfiles de aplicación que extienda el uso de los metadatos DC a distintos dominios.

● Crear un diccionario de metadatos DC.

● Utilizar los metadatos DC para el desarrollo de herramientas de catalogación electrónica.

3.3. ELEMENTOS DUBLIN CORELos metadatos Dublin Core tratan de ubicar, dentro de Internet, los datos necesarios

para describir, identificar, procesar, encontrar y recuperar un documento introducido en la red. Si este conjunto de elementos Dublin Core se lograra aceptar internacionalmente supondría que todos los procesos que indizan documentos en Internet encontrarían, en la cabecera de los mismos, todos los datos necesarios para su indización mediante datos uniformes. De esta

46

manera, se lograría estandarizar los metadatos de la cabecera de los documentos y se facilitaría su indización automática, mejorando la efectividad de los motores de búsqueda.

Hoy por hoy, existen transcripciones a 20 idiomas y ha sido adoptado por el CEN/ISS (European Committee for Standardization / Information Society Standardization System). Además , posee dos RFCs de Internet (Requests for Comments) (RFC2413) y (RFC2731) y es también el estándar oficial del WWWConsortium y el estándar Z39.50.

Los metadatos Dublin Core han sido aprobados por el organismo nacional de estandarización norteamericano (ANSI/NISO Z39.85) y los utilizan como base tanto de gobiernos como de agencias supranacionales. Muchas otras iniciativas de metadatos pertenecientes a comunidades específicas como bibliotecas, archivos, en educación, negocios, etc. también lo utilizan.

Como resultado de un consenso y un esfuerzo interdisciplinar e internacional, el DCMI se centró en el desarrollo de un conjunto de 13 elementos, que concluyeron siendo 15, para describir documentos Estos elementos poseen etiquetas descriptivas que pretenden transmitir un significado semántico a los mismos. Cada elemento es opcional, puede repetirse y aparecer en cualquier orden.

Aunque algunos entornos, como HTML, no diferencian entre mayúsculas y minúsculas, por lo que es recomendable escribir correctamente cada metadato, para evitar conflictos con otros entornos, como SGML y XML. De manera que cada uno de los 15 elementos se puede extender de acuerdo al uso de un calificador de esquema y de tipo. El calificador de esquema interpreta el valor del contenido del elemento. Para ello se basa generalmente en normas externas. Por otro lado, el calificador de tipo refina la definición del elemento en sí mismo, de forma que pueda ser útil para la recuperación y localización de recursos en Internet.

Podemos clasificar el conjunto de elementos Dublin Core en 3 grupos que indican la clase o el ámbito de la información que contienen :

1. Elementos relacionados principalmente con el contenido del recurso:

● DC.Title. Se corresponde al nombre formal dado a un recurso determinado.

● DC.Subject. Hace referencia a la temática del recurso, basándose para ello en palabras o códigos de clasificación. Como recomendación encontramos el uso de un esquema normalizado.

● DC.Description. Metadato que contiene la descripción de los contenidos de un recurso.

● DC.Source. Es una referencia a un recurso del cual proviene el recurso que actualmente se está consumiendo. Se recomienda referenciar el recurso por medio de una cadena o número de conformidad con un sistema formal de identificación.

● DC.Language. Indica la lengua del contenido intelectual del recurso. Se recomienda usar RFC 3066 (http://www.ietf.org/rfc/rfc3066.txt) en conjunción con la ISO 639 [ISO639] (http://www.loc.gov/standards/iso639-2). Ambos estándares definen etiquetas de dos y tres letras primarias para cada lenguaje, con una serie de sub-etiquetas opcionales. Ejemplo: "en" u "eng" para Inglés, "akk" para Acadio, y "en-GB" para inglés

47

usado en Reino Unido.

● DC.Relation. Es una referencia que nos permite relacionar un recurso a otro. Se recomienda referenciar el recurso por medio de una cadena de números de acuerdo con un sistemas de identificación formal.

● DC.Coverage. Nos indica la extensión o ámbito en el que se encuentra el contenido de un recurso. La cobertura incluiría la localización espacial (nombre del lugar o coordenadas geográficas donde se encuentra el recurso), el período temporal (una etiqueta del período, fecha o rango de datos) o jurisdicción (tal como el nombre de una entidad administrativa). Se recomienda seleccionar un valor de un vocabulario controlado (por ejemplo, del Thesaurus of Geographic Names (TGN), donde sea apropiado se prefiere el uso de los nombres de lugares o períodos de tiempo antes que los identificadores numéricos tales como un conjunto de coordenadas o los rangos de datos.

1. Elementos relacionados principalmente con el recurso cuando este se considera una propiedad intelectual:

● DC.Creator. Metadato que hace referencia a la entidad responsable de la creación del contenido intelectual del recurso. Un creador puede ser desde una persona, una organización o incluso un servicio.

● DC.Publisher. Es un metadato que nos indica cuál es la entidad responsable de mantener un recurso disponible.

● DC.Contributor. Hace referencia a una entidad que colabora con el contenido de un recurso.

● DC.Rights. Lleva información sobre los derechos de propiedad de un recurso. Este elemento podrá contener un estamento de gestión de derechos para el recurso o una referencia a un servicio que provea tal información. La información sobre derechos, a menudo, se corresponde con los derechos de propiedad intelectual, copyright y otros derechos de propiedad.

2. Elementos relacionados principalmente con la instanciación del recurso:

● DC.Date. Guarda la fecha de un evento del ciclo de vida de un recurso. Típicamente guarda la fecha de creación o de disponibilidad del recurso. El formato de fecha recomendado es determinado por la norma ISO 8601.

● DC.Type. Metadato que nos indica la naturaleza de un recurso. El metadato typr incluye términos que describen las categorías generales, funciones, géneros o niveles de agregación del contenido. Se recomienda seleccionar un valor perteneciente a un vocabulario controlado (por ejemplo, el DCMI Vocabulary -DCMITYPE- http://dublincore.org/documents/dcmi-type-vocabulary/). Para describir la manifestación física o digital del recurso, se usa el elemento Format.

● DC.Format. Nos ofrece una descripción física del recurso. Puede usarse para determinar el software, hardware u otro equipamiento necesario, para ejecutar u operar con el recurso. Ejemplos de las dimensiones son el tamaño y la duración del mismo.

48

Se recomienda seleccionar un valor de un vocabulario controlado (por ejemplo, la lista de Internet Media Types (MIME) que define los formatos de medios de ordenador).

● DC.Identifier. Es una referencia unívoca del recurso dentro de un contexto dado. La recomendación es usar una cadena de números conforme a un estándar determinado. Tal es el caso del uso de una URI, que incluye el Uniform Resource Locator -URL, el Digital Object Identifier (DOI) y el International Standard Book Number (ISBN).

El DCMI ya indicaba, en sus primeros momentos de desarrollo, que para promover una interoperabilidad global era necesario que se pudiera asociar una descripción del valor, de algunos de los elementos, con vocabularios controlados. También asumía el desarrollo de otros vocabularios controlados, que aseguraran dicha interoperabilidad en dominios específicos. Esto es lo que se ha hecho con los elementos DC. Format y DC. Type. Para ello se desarrolló la norma ISO 11179 sobre registros de metadatos, así como la recomendación DCMI Type Vocabulary, respectivamente. El uso de vocabularios controlados también lo encontramos en metadatos de para la lengua, fechas, etc.

3.4. EL ESQUEMA Y LOS CALIFICADORES DE DUBLIN COREComo se ha dicho, los elemento del Dublin Core son opcionales y repetibles, pero el

esquema permite además emplear calificadores opcionales. Los calificadores permiten aumentar la especificidad y la precisión de los metadatos, aunque pueden también introducir cierta complejidad que disminuiría la compatibilidad con otras aplicaciones que usen Dublin Core. Debido a esto, los desarrolladores deben escoger elementos del conjunto de calificadores aprobados por Dublin Core.

Para determinar estos calificadores, se dió preferencia a vocabularios, notaciones y términos actualmente mantenidos por agencias ya establecidas, a la espera de que los implementadores desarrollaran calificadores adicionales para sus propios dominios específicos.

Existía una recomendación sobre calificadores DCMI (Dublin Core Qualifiers) donde se establecían 2 tipos de calificadores :

• Refinación de elementos. Estos calificadores hacen que el significado de un elemento sea más estrecho o más específico. Un elemento refinado comparte el significado del elemento no calificado, pero con un alcance más restrictivo. Si un agente no entiende un término de refinamiento específico para un elemento, debe ser capaz de ignorarlo y tratar el valor del metadato como si estuviese sin calificar. Las definiciones de términos para refinamiento de elementos deben estar públicamente disponibles.

• Esquema de codificación (scheme). Estos calificadores identifican esquemas que ayudan en la interpretación del valor de un elemento. Estos esquemas incluyen vocabularios controlados y notaciones formales o reglas de parseo. Un valor expresado usando un esquema de codificación será un símbolo (token), escogido de un vocabulario controlado (por ejemplo, un término de un sistema de clasificación) o una cadena (string) con formato de acuerdo con una notación formal (por ejemplo, "2002-01-01" como la expresión estándar de una fecha). Si un esquema de codificación no es entendido por un

49

agente, el valor será de todas maneras, útil para un lector humano. La descripción definitiva de un esquema de codificación para calificadores debe estar claramente identificada y disponible para uso público.

Encontramos un ejemplo en el calificador “Alternative”, que hace referencia a cualquier alternativa usada para sustituir al título formal del recurso, es un calificador que refina el elemento “Title”; o los calificadores “Table Of Contents” (Tabla de Contenido) y “Abstract” (Resumen) son calificadores que refina el elemento “Description”. Y existen calificadores no sólo para refinar el título o la descripción, sino también para refinar la materia, la fecha, el tipo de recurso, el formato, la relación, la cobertura, etc.

Algunos ejemplos de esquemas de codificación serían la clasificación DDC (Dewey Decimal Classification) o LCC (Library of Congress Classification) para materia, o Período DCMI (DCMI Period) para fecha (http://dublincore.org/documents/dcmi-period).

Hoy por hoy, los calificadores, tanto si hacen referencia a los elementos refinados como a los esquemas de codificación, han sido incluidos dentro de la especificación "DCMI Metadata Terms" http://dublincore.org/documents/dcmi-terms.

A continuación, se muestran 2 tablas que recogen dichos elementos refinados y los esquemas de codificación, extraídos de "DCMI Metadata Terms" (http://dublincore.org/documents/dcmi-terms/).

50

ETIQUETA DEL ELEMENTO DC DESCRIPCIÓN

abstract Un sumario del contenido del recurso

accesRights Información acerca de quién puede acceder al recurso o una dirección

de su estatus de seguridad

accrualMethod El método por el cual los items se añaden a una colección

accrualPeriodicity Frecuencia con la que los items son añadidos

alternative Subtitulo o alternativa al título oficial del recurso

audience Indica para quién está indicado el recurso

avaliable Fecha en la que el recurso comienza a estar disponible

bibliographicCitation Referencia bibliográfica del recurso

conformsTo Referencia a un estándar con el cual está de acuerdo el recurso

created Fecha de creación del recurso

dateAccepted Fecha de aceptación del recurso

dateCopyrigthted Fecha del establecimiento del Copyright

issued Fecha de circulación del recurso

isFormatOf El recurso descrito tiene el mismo contenido intelectual que el recurso

referido, pero presentado en otro formato

medium Material o sustancia física de la que está formada el recurso

modificied Fecha en la que se ha modificado un recurso

references Referencias de los recursos descritos, citas, u otros puntos de vistas que

se refieren al recurso

TableOfContents Una lista de sub-unidades del contenido del recurso

Tabla 3. Elementos refinados de Dublin Core.

La tabla anterior es sólo un extracto. La lista completa y detallada tanto de los elementos principales, como de elementos refinados, los esquemas de codificación y los términos del vocabulario (DCMI Type Vocabulary), pueden consultarse en la especificación de todos los términos de metadatos mantenidos por el Dublin Core: "DCMI Metadata Terms".

51

En cuanto a los esquemas codificados (scheme), podemos encontrar los siguientes:

ESQUEMAS CODIFICADOS DEFINICIÓN

Box El DCMI Box identifica una región del espacio usando sus límites geográficos

DCMIType Una lista de los tipos usados para categorizar la naturaleza o género del contenido de un recurso

DDC Clasificación Decimal de Dewey (Dewey Decimal Classification)

IMT Los tipos de media de Internet del recurso

ISO3166 ISO 3166 Códigos para la representación de nombres de países (http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html)

ISO639-2 ISO 639-2: Códigos para la representación de nombres de idiomas (http://lcweb.loc.gov/standards/iso639-2/langhome.html)

LCC Calificación de la Biblioteca del Congreso (http://lcweb.loc.gov/catdir/cpso/lcco/lcco.html)

LCSH Encabezamientos de la Biblioteca del Congreso (http://lcweb.loc.gov/cds/lcsh.html)

MeSH (Medical Subject Headings) Encabezamientos para materas médicas (http://www.nlm.nih.gov/mesh/meshhome.html)

Period Especifica los límites de un intervalo de tiempo. (http://dublincore.org/documents/dcmi-period/)

Point Identifica un punto en el espacio mediante coordenadas geográficas. ((http://dublincore.org/documents/dcmi-point/)

RFC1766 La Internet RFC 1766 'Tags for the identification of Language' o Etiquetas para la identificación de idioma, especifica un código de dos letras tomado de la ISO 639, seguido opcionalmente por otras dos letras del código del país tomado de la ISO 3166. (http://www.ietf.org/rfc/rfc1766.txt)

RFC3066 Internet RFC 3066 'Tags for the Identification of Languages' especifica una sub-etiqueta que tiene un código de dos letras tomados de la ISO 639 part 1 o un código de tres letras tomado de la ISO 639 part 2, seguido opcionalmente de un código de país de dos letras tomado de la ISO 3166. Cuando un idioma en la ISO 639 tiene dos letras en ambos y un código de tres letras, se usa el código de dos letras; cuando éste tiene solamente un código de tres letras, se usa el código de tres letras Esta RFC reemplaza a la RFC 1766. (http://www.ietf.org/rfc/rfc3066.txt)

TGN Tesauro Getty de Nombres Geogoráficos (The Getty Thesaurus of Geographic Names). ( http.//www.getty.edu/research/tools/vocabulary/tgn/ondex.html)

UDC Clasificación Decimal Universal (Universal Decimal Classification). (http://www.udcc.org/)

URI Un URI o Uniform Resource Identifier. (http://www.ietf.org/rfc/rfc2396.txt)

W3CDTF Reglas de codificación W3C para fechas y tiempos (W3C Encoding rules for dates and times) - un perfil basado en la ISO 8601. (http://www.w3.org/TR/NOTE-datetime)

Tabla 4. Esquemas de codificación para elementos de Dublin Core.

52

En cuanto, al Tipo (The DCMI Type Vocabulary), los términos empleados en DCMI son los siguientes:

NOMBRE DEL TÉRMINO DEFINICIÓNCollection Una “colección” es una suma de ítems. El término colección significa

que el recurso se describe como un grupo; sus partes pueden ser descritas y navegadas separadamente.

Dataset A “conjunto de datos” es una información codificada en una estructura definida (por ejemplo, listas, tablas y bases de datos), con el fin de que puedan ser usadas de forma directa por un proceso mecánico.

Event Un “evento” es un suceso no persistente basado en el tiempo. El metadato para un evento ofrece información descriptiva que es la base para descubrir el objeto, localización, duración, agentes responsables y enlaces a sucesos relacionados y recursos. El recurso del tipo de evento puede no ser recuperable si la instanciación descrita ha expirado o está todavía por ocurrir. Ejemplos - exhibición, lanzamiento de web, conferencia, taller, estreno, competición, boda, etc.

Image Una “imagen” es una representación visual primariamente simbólica diferente a un texto. Por ejemplo -imágenes y fotografías de objetos físicos, pinturas, impresiones, dibujos, otras imágenes y gráficos, animaciones y dibujos en movimiento, películas, diagramas, mapas, notaciones musicales. Hay que hacer notar que una imagen puede incluir tanto representaciones electrónicas como físicas.

InteractiveResource Un “recurso interactivo” es un recurso que requiere interacción del usuario para ser comprendido, ejecutado o experimentado. Por ejemplo - formularios en páginas web, applets, objetos de aprendizaje multimedia, servicios de chat, realidad virtual.

MovingImage Una “imagen en movimiento” es una serie de representaciones visuales que, cuando se muestran en sucesión, dan una impresión de movimiento. Ejemplos de imágenes en movimiento son: animaciones, películas, programas de televisión, vídeos, zootropos, u otras salidas visuales de una simulación.

PhysicalObject Una cosa u objeto en tres dimensiones o materia. Por ejemplo - un ordenador, la gran pirámide, una escultura. Nótese que las representaciones digitales o los sustitutos de estas cosas usarían Image, Text u otro tipo.

Service Un “servicio” es un sistema que ofrece una o más funciones de valor para el uso final. Ejemplos son: un servicio de copias de fotos, un servicio bancario, un servicio de autentificación, préstamo interbibiliotecario, un servidor Z39.50 o un servidor Web.

Software “Software” es un programa de ordenador en forma de fuente o compilado que puede estar disponible para su instalación en otra máquina. Para software que existe solamente para crear un ambiente interactivo, se usa interactive.

Sound Un “sonido” es un recurso cuyo contenido es primariamente entendido para ser reproducido como audio. Por ejemplo - un formato de archivo para reproducir música, un CD de audio, y conversaciones o sonidos grabados.

StillImage Una “representación visual estática” Ejemplo de imágenes estáticas son: pinturas, dibujos, diseños gráficos, planos y mapas.

Text Un “texto” es un recurso cuyo contenido es primordialmente palabras para la lectura. Por ejemplo, -libros, cartas, dissertations, poemas, periódicos, artículos, archivos de listas de correo. Nótese que los facsímiles o imágenes de texto son still del género texto.

Tabla 5. Elementos empleados en Dublin Core

53

A modo de resumen de todo lo anterior, vamos a presentar la siguiente tabla, en la cual encontramos los 15 elementos de definidos por Dublin Core:

NOMBRE DESCRIPCIÓN ESQUEMA TIPO ETIQUETATítulo Nombre dado a un recurso u

objeto● Interno*● AACR2

● Principal● Alternativo

DC.Title

Autor o creador

Persona(s) responsable(s) del contenido intelectual del recurso u objeto

● Interno*● USMARC

● Nombre● Correo

electrónico

DC.Author

Encabezamiento Direcciona hacía los tópicos

que describen el título o contenido del recurso u obejto

● Interno*● LCSH● UDC● DDC● NLM● Etc.

● Palabras o frases claves separadas por comas

● Notas acerca del recurso

DC.Subject

Descripción Descripción textual del recurso ● Interno*● URL● URN

● Texto libre● Resumen

DC.Description

Editor Entidad responsable de hacer que un recurso se encuentre en la red

● Interno*● USMARC

● Nombre● Correo

electrónico

DC.Publisher

Otros Colaboradores**

Persona(s) que hayan hecho alguna contribución intelectual adicional significativa al trabajo

● Interno*● USMARC

● Nombre ● Correo

electrónico

DC.Contributor

Fecha de publicación

Fecha en la que se puso el recurso a disposición del usuario

● IETF.RFC-822ANSI.X3.30-1985

● ISO● FGDC, etc.

● Fecha de creación

DC.Date

Tipo de recurso u objeto

Categoría o género del recurso ● DC Objects.*● Texto libre

DC.Type

Formato Formato de los datos ● IMT● MIME● Texto Libre

DC.Format

Identificador Identificador único del recurso u objeto

● URL● URN● ISBN● FPI● Número de

Versión

● Primera versión del recurso

● Copia de la versión original del recurso

DC.Identifier

Fuente Identificador único de un trabajo a partir del cual proviene el recurso actual

● Texto libre● URL● URN● ISBN● ISSN● FPI

DC.Source

Idioma Idioma del contenido intelectual ● Texto libre.*● Z3953● ISO.639● Lenguaje

Cómputo

DC.Language

Relación Un identificador de un segundo recurso y su relación con el actual

● URL*● URN● ISBN● ISSN● FPI

● Texto libre DC.Relation

54

NOMBRE DESCRIPCIÓN ESQUEMA TIPO ETIQUETACobertura Características de cobertura

espacial y temporal de un recurso

● Latitud y Longitud● OSGB● ANSI.X3.30-1985● Texto libre

● Espacial ● Temporal

DC.Coverage

Derechos Notas sobre derechos de autor. Uso experimental

● Texto libre.*● URL● URN

DC.Rights

Tabla 6. Tabla resumen de los quince elementos definidos por el Dublin Core.

3.5. EJEMPLOS: METADATOS DC CON ETIQUETAS DE DISTINTOS ESTÁNDARES

Así pues, los metadatos Dublin Core han tenido un desarrollo espectacular en los últimos años y se han convertido en un estándar de metadatos con un alcance internacional en diferentes ámbitos y sectores. Desde sus primeras aplicaciones, en la descripción por medio de etiquetas HTML, hasta sus últimos desarrollos en lenguaje RDF/XML, con el uso de namespaces, esquemas, etc. los metadatos DC se han mostrado como un método válido para describir distintas áreas del conocimiento y existen todavía numerosos proyectos en marcha en campos que no sólo tienen que ver con el campo de la biblioteconomía y documentación, el arte y las humanidades, sino también con la educación, el comercio, la ciencia y la tecnología, etc.

El conjunto de elementos DC es multidisciplinar e internacional y es extensible, ya que permite agregar modificaciones y revisiones de acuerdo con una materia específica o una necesidad concreta. Es posible crear perfiles para adaptarlo a una aplicación concreta.

Las ventajas de usar metadatos Dublin Core, aparte de que representan un estándar muy extendido a nivel internacional y en distintas disciplinas, es la facilidad de su uso. De hecho, se ha convertido en un modelo de descripción de datos semántico a través de RDF. Además, Dublin Core se usa junto con otros otros perfiles de aplicación. Por ejemplo, el protocolo Z39.50 para el intercambio entre sistemas bibliotecarios, acordó incluir los 15 elementos de los metadatos Dublin Core como formato aceptado y, de esta forma, se pueden recuperar los elementos DC especificándolos en las búsquedas.

Vamos a ver como se usan algunos de los metadatos DC usando formatos como el HTML,XML o XML/RDF, para hacernos una idea de que como se utilizan algunos de los elementos que conforman el estándar Dublin Core:

a) Ejemplo de metadatos Dublin Core en HTML extraído de DCMI: Expressing Dublin Core in HTML/XHTML meta and link elements (http://dublincore.org/documents/dcg-html/):

...<head profile="http://dublincore.org/documents/dcq-html/"><title>Expressing Dublin Core in HTML/XHTML meta and link elements</title><link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" /><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" /><meta name="DC.title" lang="en" content="Expressing Dublin Core in HTML/XHTML meta and link elements" />

55

<meta name="DC.creator" content="Andy Powell, UKOLN, University of Bath" /><meta name="DCTERMS.issued" scheme="DCTERMS.W3CDTF" content="2003-11-01" /><meta name="DC.identifier" scheme="DCTERMS.URI" content="http://dublincore.org/documents/dcq-html/" /><link rel="DCTERMS.replaces" hreflang="en"href="http://dublincore.org/documents/2000/08/15/dcq-html/" /><meta name="DCTERMS.abstract" content="This document describes how qualified Dublin Core metadata can be encoded in HTML/XHTML &lt;meta&gt; elements"/><meta name="DC.format" scheme="DCTERMS.IMT" content="text/html" /><meta name="DC.type" scheme="DCTERMS.DCMIType" content="Text" /></head>...

b) Ejemplo de uso de metadatos DC con un formato XML extraído de DCMI: Guidelines for implementing Dublin Core in XML (http://dublincore.org/documents/dc-xml-guidelines/):

<?xml version="1.0"?>

<metadata

xmlns="http://example.org/myapp/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://example.org/myapp/ http://example.org/myapp/schema.xsd"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<dc:title>

UKOLN

</dc:title>

<dc:description>

UKOLN is a national focus of expertise in digital information

management. It provides policy, research and awareness services

to the UK library, information and cultural heritage communities.

UKOLN is based at the University of Bath.

</dc:description>

<dc:publisher>

UKOLN, University of Bath

</dc:publisher>

<dc:identifier>

http://www.ukoln.ac.uk/

</dc:identifier>

56

</metadata>

c) Ejemplo de uso de metadatos Dublin Core en XML/RDF extraído de DCMI: Expressing Simple Dublin Core in RDF/XML (http://dublincore.org/documents/dcmes-xml/):

<?xml version="1.0"?><!DOCTYPE rdf:RDF PUBLIC "-//DUBLIN CORE//DCMES DTD 2002/07/31//EN""http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd"><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc ="http://purl.org/dc/elements/1.1/"><rdf:Description rdf:about="http://dublincore.org/"><dc:title>Dublin Core Metadata Initiative - Home Page</dc:title><dc:description>The Dublin Core Metadata Initiative Web site.</dc:description><dc:date>2001-01-16</dc:date><dc:format>text/html</dc:format><dc:language>en</dc:language><dc:contributor>The Dublin Core Metadata Initiative</dc:contributor><!-- guesses for the translation of the above titles --><dc:title xml:lang="fr">L'Initiative de mitadonnies du Dublin Core</dc:title><dc:title xml:lang="de">der Dublin-Core Metadata-Diskussionen</dc:title></rdf:Description></rdf:RDF>

4. EL ESTÁNDAR DE METADATOS LOM

4.1. INTRODUCCIÓNLos metadatos son información añadida a los materiales digitales que facilitan su

clasificación y posterior recuperación. La especificación de metadatos adecuados para los materiales educativos es indispensable si queremos poder reutilizarlos de una manera eficiente.

Efectivamente, los materiales enriquecidos convenientemente con metadatos podrán almacenarse en bibliotecas digitales de contenidos educativos (por ejemplo, repositorios de objetos de aprendizaje), donde se podrán realizar consultas significativas que permitirán la recuperación de aquellos materiales almacenados, que cubran una determinada necesidad pedagógica.

De hecho, las ideas básicas subyacentes al uso de metadatos han sido utilizadas durante siglos por los expertos en documentación en la organización de ingentes archivos documentales y bibliotecas. Nuevamente podemos recurrir al ejemplo de la signatura asociada a un libro en una biblioteca, que ya alguna vez hemos comentado (para clarificar el sentido y la importancia de los metadatos) y que facilita su búsqueda y recuperación por parte de un bibliotecario.

La utilidad de un esquema de metadatos radica en su aceptación por parte de una comunidad suficientemente amplia de productores y consumidores de material educativo.

57

Efectivamente, si dos comunidades utilizan esquemas de metadatos distintos, difícilmente los materiales producidos podrán coexistir en un mismo repositorio, a menos que se haya encontrado previamente un consenso que permita homogeneizar los metadatos utilizados por ambas comunidades (por ejemplo, transformándolos a un esquema común). Es por ello que, desde la comunidad de e-learning (propuesta de formación que contempla su implementación predominantemente mediante Internet, haciendo uso de los servicios y herramientas que esta tecnología provee), se han realizado distintos esfuerzos para estandarizar los esquemas de metadatos que deben ser utilizados en la producción de contenidos educativos.

El esfuerzo más prometedor ha desembocado en el estándar IEEE LOM (del inglés, Learning Object Metadata) (ver IEEE LOM 2002), estándar que también ha sido adoptado, en una versión preliminar, como una especificación de descripción de metadatos por IMS (ver IMS META 2001).

El estándar LOM busca cumplir los siguientes objetivos:facilitar la búsqueda, evaluación, adquisición y uso de objetos de aprendizaje, entendiendo como objetos de aprendizaje una entidad digital o no, que contiene información usada para el aprendizaje, formación o educación de las personas.

Los metadatos de LOM se agrupan en categorías, que son un grupo de metadatos que se encuentran relacionados entre sí, ya que describen alguna de las características más importantes de un determinado objeto de aprendizaje. Veamos un esquema conceptual de lo que hemos dicho:

Figura 11. Estructura general de metadatos LOM.

1. Categoría general. Los metadatos en esta categoría representan información general sobre el material educativo que describe el mismo como un todo.

2. Categoría lifecycle (ciclo de vida). Esta categoría agrupa metadatos referidos a la historia y estado actual del proceso de producción y mantenimiento del material educativo por parte de los autores.

3. Categoría metametadata (meta-metadatos). Esta categoría agrupa información relativa a los metadatos en sí (de ahí su nombre).

4. Categoría technical (técnica). Categoría que agrupa metadatos relativos a las características y requisitos técnicos del material en sí.

58

5. Categoría educational (educativa). Categoría que agrupa metadatos relativos a los usos educativos del material.

6. Categoría rights (derechos). Categoría que agrupa metadatos relativos a los derechos de propiedad e intelectuales del material.

7. Categoría relation (relación). Categoría de metadatos utilizados para establecer relaciones entre el material y otros materiales.

8. Categoría annotation (anotación). Anotaciones y comentarios sobre el material educativo.

9. Categoría classification (clasificación). Metadatos para la clasificación del material en taxonomías.

Vamos a explicar de una forma un poco más detallada cada una de las distintas categorías que conforman el estándar.

4.2. CATEGORÍAS EN LAS QUE SE AGRUPAN LOS METADATOS LOM

4.2.1. CATEGORÍA GENERAL

Está categoría aglutina un total de 9 metadatos distintos, como queda reflejado en el siguiente gráfico:

Figura 12. Estructura del metadato general.

1. identifier (identificador). Identificador descriptivo del material educativo. Su valor debe identificar unívocamente el material en su contexto educativo.

2. title (título). Nombre descriptivo del material educativo.

3. catalogentry (entrada en catálogo). Entrada en un determinado catálogo. El valor para este metadato debe ser un par formado por un nombre de catálogo, así como por el nombre de la entrada en dicho catálogo. Este metadato puede especificarse para seleccionar el recurso cuando éste se encuentra indexado en un catálogo externo.

4. language (idioma). El idioma primario utilizado en el material para comunicarse con los potenciales consumidores del mismo.

59

5. description (descripción). Texto describiendo el contenido del material.

6. keyword (palabra clave). Colección de frases que representan palabras clave sobre el material.

7. coverage (cobertura). Eventos temporales, culturales o geográficos asociados con el material.

8. structure (estructura). La estructura interna del material. LOM define el siguiente vocabulario controlado para describir la estructura: collection (colección), mixed (mixta), linear (lineal), hierachical (jerárquica), networked (en red), branched (ramificada), parceled (compartimentada), atomic (atómica). No obstante, los autores pueden utilizar sus propios vocabularios, adaptados a sus necesidades pedagógicas particulares.

9. aggregationlevel (nivel de agregación). Define la granularidad del material. LOM define el siguiente vocabulario controlado para definir dicha granularidad

4.2.2. CATEGORÍA LIFECYCLE

La categoría lifecycle se compone de solamente tres tipos de metadatos. Vamos a mostrar un esquema de la estructura de esta categoría, así como explicaremos de forma breve cada uno de los metadatos que la componen.

Figura 13. Estructura del metadato lifecyle.

1. version. La edición o versión del material.

2. status. El estado de producción del material. LOM propone el siguiente vocabulario para este metadato (aunque puede utilizarse cualquier otro): draft (borrador), final, revised (revisado), unavailable (no disponible).

3. contribute (contribución). Introduce información acerca de un contribuyente a la producción del material. De esta forma, un mismo material puede tener asociados múltiples contribuyentes. La información de cada contribuyente puede incluir las siguientes características (aunque no es necesario que incluya todas)

60

3.1 El papel del contribuyente en el proceso de producción. LOM propone el siguiente vocabulario controlado para este metadato: autor, publisher (publicador), unknown (desconocido), initiator (iniciador), terminator (finalizador), validator (validador), editor (editor), graphical designer (diseñador gráfico), technical implementer (implementador técnico), content provider (proveedor de contenidos), technical validator (validador técnico), educational validator (validador pedagógico), script writer (escritor de guiones), instructional designer (diseñador pedagógico).

3.2 La identidad del contribuyente. Tiene sentido especificar varias identidades para el mismo contribuyente (por ejemplo, en el caso en que éste tenga varias afiliaciones).

3.3 La fecha de la contribución.

4.2.3. CATEGORÍA META-METADATA

La figura 14 esquematiza los metadatos englobados en la categoría metametadata. Es interesante notar que aparecen de nuevo elementos ya contemplados en las anteriores categorías, aunque esta vez su significado es diferente y se refieren a la producción de los metadatos como recurso digital, no a la producción del material educativo que se está anotando. El esquema es el siguiente:

Figura 14. Estructura del metadato metametadata.

1. identifier. Identificador del conjunto de metatados para el recurso. Este identificador puede utilizarse para seleccionar el conjunto de metadatos cuando éste se encuentra almacenado externamente.

2. catalogentry. Un catálogo y una entrada en dicho catálogo con el conjunto de metadatos para el recurso reside. Esto permite seleccionar los metadatos de un catálogo externo.

3. contribute. Contribuyente a la elaboración de estos metadatos. Para cada contribuyente es posible especificar, al igual que en la categoría lifecycle, el rol, la identidad y la fecha. LOM proporciona un vocabulario controlado para el rol, que, en este caso, puede ser: creator (creador) y validator (validador).

4. metadatascheme (esquema de metadatos). Esquema de metadatos utilizado (por ejemplo, LOMv1.0). Obsérvese que es posible haber usado más de un esquema (por ejemplo, en el caso de que se haya realizado una especialización o perfil de aplicación de

61

uno ya existente).

5. language. El idioma por defecto utilizado para proporcionar los metadatos.

4.2.4. CATEGORÍA TECHNICAL

Esta categoría engloba 7 nuevos metadatos, representados en la siguiente figura:

Figura 15. Estructura del metadato technical.

1. format (formato). Formato del material. Dado que el material no tiene porque ser atómico, es posible que integre múltiples formatos (por ejemplo, una página web puede integrar un documento HTML con un conjunto de imágenes JPG), por lo que un mismo material puede exhibir múltiples metadatos format. Una manera adecuada de describir los formatos es mediante su denominación MIME .

2. size (tamaño). Tamaño en bytes del material.

3. location (localización). Forma de localizar al material (por ejemplo, una URL, o una descripción textual acerca de cómo llevar a cabo dicha localización).

4. requirement (requisito). Plataforma informática necesaria para utilizar este material. Dicha plataforma puede describirse en términos de las siguientes características:

4.1 Tipo de la plataform. LOM propone el siguiente vocabulario para el tipo: browser (navegador), operating system (sistema operativo).

4.2 Nombre de la plataforma. LOM propone el siguiente vocabulario: (i) en caso de que el tipo sea operating system: PC-DOS, MS-Windows, MacOS, Unix, Multi-OS, None; (ii) en caso de que el tipo sea browser: Any (cualquiera), Netscape Communicator, Microsoft Internet Explorer, Opera, Amaya.

5. instalationremarks (indicaciones de instalación). Notas de instalación para el recurso.

6. otherplatformrequeriments (otros requisitos de plataforma). Otros requisitos software y hardware.

7. duration (duración). Duración (únicamente para material para el que tenga sentido una duración en su reproducción, como, por ejemplo, un video o una presentación Flash).

62

4.2.5. CATEGORÍA EDUCATIONAL

Pasamos a mostrar en la siguiente figura los metadatos contenidos en la categoría “educational”, para dar luego una breve explicación de cada uno de ellos.

Figura 16. Estructura del metadato educational.

1. interactivitytype (tipo de interacción). Tipo de interacción soportado por el material. LOM propone el siguiente vocabulario para caracterizar este tipo de interacción: active (para los contenidos interactivos), expositive (para los contenidos pasivos), mixed (para contenidos que comparten ambas características), undefined (para contenidos para los que no procede especificar el tipo de interacción).

2. learningresourcetype (tipo de recurso educativo). Especifica el tipo de material (por ejemplo, ejercicio, figura, etc.). Un mismo material puede tener distintos tipos asociados. LOM propone el siguiente vocabulario para caracterizar el tipo de material: exercise (ejercicio), simulation (simulación), questionnarie (cuestionario), diagram (diagrama), figure (figura), graph (gráfico), index (índice), slide (diapositiva), table (tabla), narrative text (texto narrativo), exam (examen), experiment (experimento), ProblemStatement (enunciado de problema), SelfAssessment (autoevaluación).

3. interactivitylevel (nivel de interacción). Especifica el nivel de interacción del material. LOM propone el siguiente vocabulario controlado para especificar dicho nivel: very low (muy bajo), low (bajo), medium (medio), high (alto), very high (muy alto).

4. semanticdensity (densidad semántica). Una medida subjetiva de la utilidad educativa del material en comparación con su tamaño y/o duración. LOM propone usar para expresar este nivel el mismo vocabulario controlado que para interactivitylevel.

5. intendeduserrole (papel jugado por el supuesto usuario). Determina el papel del usuario final del material. LOM propone el siguiente vocabulario para describir dicho papel: teacher (maestro), author (autor), learner (aprendiz), manager (gestor).

6. context (contexto). El entorno educativo típico en el que se usará el material. LOM propone el siguiente vocabulario: primary education (educación primaria), secondary education (educación secundaria), higher education (educación superior), university first cycle (primer ciclo universitario), university second cycle (segundo ciclo universitario), university postgrade (postgrado), technical school first cycle (primer ciclo de escuela técnica), technical school second cycle (segundo ciclo de escuela técnica), professional formation (formación profesional), continuous formation (formación continua), vocational

63

training (formación vocacional).

7. typicalagerange (segmento de edad típico). Rango de edades típico de los usuarios a los que va dirigido el material.

8. difficulty (dificultad). Grado de dificultad del material. LOM propone el siguiente vocabulario para caracterizar dicho grado: very easy (muy fácil), easy (fácil), medium (medio), difficult (difícil), very difficult (muy difícil).

9. typicallearningtime (tiempo típico de aprendizaje). Tiempo de aprendizaje típico asociado con el material.

10. description (descripción). Comentarios sobre el uso del material desde un punto de vista pedagógico.

11. language (idioma). Idioma del usuario final.

4.2.6. CATEGORÍA RIGTHS

Los metadatos que componen esta categoría son los siguientes:

Figura 17. Estructura del metadato rigths.

1. cost (coste). Establece si el recurso es o no de pago. LOM propone como vocabulario controlado para este metadato el siguiente: yes, no.

2. copyrightandotherrestrictions (derechos de copia y otras restricciones). Establece si el recurso está o no sujeto a derechos de copia y otras restricciones. LOM propone como vocabulario controlado para este metadato, de nuevo, yes y no.

3. description (descripción). Comentarios sobre las condiciones y derechos de uso de este recurso.

4.2.7. CATEGORÍA RELATION

La categoría relation considera los metadatos referidos a la relación existente entre distintos materiales. Un mismo material puede mantener múltiples relaciones con otros materiales. Cada una de estas relaciones exhibe las siguientes características:

64

1. La clase de la relación. LOM propone el siguiente vocabulario controlado para caracterizar dicha clase: isPartOf (el material es parte de otro más complejo), hasPart (el material tiene a otro como parte integrante), isVersionOf (el material es una versión de otro), hasVersion (el material tiene a otro como una versión), isFormatOf (el material es la descripción de un formato de otro material), hasFormat (el material tiene a otro como formato), references (el material refiere al otro), isReferencedBy (el material está referido por el otro), isBasedOn (el material está basado en otro), isBasisFor (el material es la base de otro), requires (el material requiere la presencia de otro), isRequiredBy (el material es requerido por otro). La caracterización del otro material con el que se establece la relación puede darse en términos de:

•El identificador único del otro material.

•La descripción del otro material.

•Una entrada en un catálogo para el otro material.

4.2.8. CATEGORÍA ANNOTATION

Los materiales pueden tener asociados múltiples anotaciones. Dichas anotaciones pueden caracterizarse por:

1. El anotador que realiza la anotación.

2. La fecha de la anotación.

3. El texto en sí de la anotación

4.2.9. CATEGORÍA CLASSIFICATION

LOM permite someter a los materiales a múltiples clasificaciones. Cada clasificación puede tener asociada la siguiente información:

1. El propósito de la clasificación. LOM propone el siguiente vocabulario controlado de propósitos: discipline (disciplina), idea, prerequisite, educational objective (objetivo educativo), accesibility restrictions (restricciones de acceso), educational level (nivel educativo), skill level (nivel de destreza), security level (nivel de seguridad).

2. Una serie de rutas en distintas taxonomías.

3. Una descripción textual del material relativa al propósito de clasificación establecido.

4. Un conjunto de palabras clave relativas al propósito de clasificación establecido.

4.3. REPRESENTACIÓN DE LOS METADATOS LOM EN XMLLos metadatos LOM pueden codificarse en múltiples formatos (por ejemplo, XML, o

RDF). De estos, la codificación en XML es especialmente interesante ya que permite el uso combinado de la especificación con otras, como por ejemplo IMS CP.

65

En este apartado se describe la codificación en XML de LOM. Comienza describiéndose la estructura general de la codificación y a continuación se describe la codificación la categoría “General” a modo de ejemplo, con el resto de metadatos se seguiría una actuación muy similar. La Figura 18 muestra la estructura gramatical general de la codificación de metadatos LOM en XML.

De esta forma, se introducen elementos para cada una de las categorías, observe que la presencia de todos los elementos es opcional. Si no existen metadatos para una categoría dada, no es preciso especificar el elemento para dicha categoría. No obstante, el orden de aparición de los elementos debe ser el indicado.

Figura 18. Estructura de metadatos LOM en XML.

Con la siguiente figura se esquematiza el aspecto general de la codificación XML de los metadatos del caso de estudio. El prefijo lom: se asume asociado con el espacio de nombres para el esquema de dicha codificación, siguiendo los mecanismos explicados en el capítulo sobre IMS CP.

Tengamos en cuenta que, dado que en este ejemplo se han especificado metadatos para todas las categorías, en la codificación XML aparecen todos los elementos indicados. No obstante, en casos de aplicación más realistas esto no tiene porque ser necesariamente cierto.

Aspecto general de la codificación XML de los metadatos del caso de estudio:

66

Figura 19. Codificación XML de metadatos LOM.

Por último, a modo de ejemplo que nos ayude a entender como se codificaría en XML un metadato LOM, exponemos la codificación XML del metadato “general”. Las principales características de dicha estructura son:

● Siempre que es preciso introducir una descripción textual, dicha descripción se introduce mediante un elemento langstring. Dicho elemento puede tener asociado un atributo xml:lang (este atributo no se indica en el esquema por simplicidad), que especifica el idioma del texto. De hecho, siempre es posible utilizar múltiples langstring alternativos para una misma descripción introduciendo textos en distintos idiomas (dichos elementos deben diferir en el valor del atributo xml:lang).

● En el caso de metadatos como structure o aggregationlevel, admiten vocabularios controlados mediante el metadato source. Para ello, debe introducirse la denominación del vocabulario mediante el término value. Este patrón se repite de forma recursiva en la codificación de otros muchos metadatos tal y como se examinará más adelante.

67

En catalogentry se sigue un esquema de codificación específico de entradas en catálogos que también se adopta para otros metadatos en LOM. Mediante catalog se identifica el nombre del catálogo, y mediante entry la descripción de la entrada.

La estructura gramatical para la codificación de la categoría general y del código XML se muestran a continuación:

Figura 20. Estructura gramatical para la codificación de la categoría general.

68

Figura 21. Codificación XML del metadato general.

69

5. EL ESTÁNDAR DE METADATOS RDF

5.1. INTRODUCCIÓNEs muy difícil automatizar cualquier cosa en la Web. Debido al enorme volumen de

información que contiene no es posible gestionarla manualmente. La solución que se propone aquí es el uso de metadatos para describir los recursos Web.

La distinción entre "datos" y "metadatos" no es incuestionable; es una diferencia creada en primera instancia por una aplicación particular. Muchas veces el mismo recurso se interpretará de ambas formas, tanto como dato como metadato de manera simultánea.

RDF (Resource Description Framework) o Infraestructura para la Descripción de Recursos, es una base para procesar metadatos permitiendo la interoperabilidad entre aplicaciones que intercambian información legible por una máquina en la Web.

RDF destaca por la facilidad para habilitar el procesamiento automatizado de los recursos Web. Además puede utilizarse en distintas áreas de aplicación: en recuperación de recursos para proporcionar mejores prestaciones a los motores de búsqueda, en catalogación para describir el contenido y las relaciones de contenido disponibles en un sitio Web, una página Web, o una biblioteca digital particular, por los agentes de software inteligentes para facilitar el intercambio y para compartir conocimiento; en la calificación de contenido, para describir los derechos de propiedad intelectual de las páginas web, etc. RDF junto con las firmas digitales serán la clave para construir una "Web de confianza" para el comercio electrónico, la cooperación y otras aplicaciones.

El objetivo general de RDF es definir un mecanismo para describir recursos que no cree ninguna asunción sobre un dominio de aplicación particular, ni defina (a priori) la semántica de algún dominio de aplicación. La definición del mecanismo debe ser neutral con respecto al dominio, sin embargo, el mecanismo debe ser adecuado para describir información sobre cualquier dominio. Para facilitar la definición de metadatos, RDF contará con un sistema de clasificación muy parecido a los sistemas de programación y modelado orientado a objetos. Una colección de categorías (producida normalmente para un propósito o dominio específico) denominada schema.

Las categorías RDF se organizan en una jerarquía, y proporcionan extensibilidad a través de un refinamiento de las mismas mediante subcategorías. De esta forma, para crear un esquema ligeramente diferente de uno ya existente no es necesario que "reinventemos la rueda", sólo tenemos que introducir las modificaciones incrementales necesarias al esquema base.

Gracias a la extensibilidad incremental de RDF, los agentes que procesen metadatos serán capaces de trazar los orígenes de un esquema y realizar acciones significativas en los metadatos para los que no han sido diseñados inicialmente para procesar. Gracias a la capacidad de compartir, y a la extensibilidad de RDF, los creadores de metadatos pueden usar múltiples cambios de la categoría de objetos, para "mezclar" definiciones o proporcionar múltiples presentaciones a sus datos, haciendo uso del trabajo de otros. En resumen, es posible crear objetos específicos de datos basados en diversos esquemas de distintas fuentes (p. ej.

70

"intercalando" diferentes tipos de metadatos).

5.2. MODELO BÁSICO DE RDFEl fundamento, o base de RDF, es un modelo que permite representar propiedades

designadas y asignar los valores de dichas propiedades. Las propiedades RDF pueden recordarnos a atributos de recursos y en este sentido se corresponden con los tradicionales pares de atributo-valor. Además, representan también las relaciones existentes entre recursos, por lo que un modelo RDF puede parecer un diagrama entidad-relación. En terminología del diseño orientado a objetos, los recursos corresponden con objetos y las propiedades corresponden con objetos específicos y variables de una categoría.

El modelo de datos de RDF es una forma de sintaxis-neutral para representar expresiones RDF. La representación del modelo de datos se usa para evaluar la equivalencia en significado, de forma que, dos expresiones RDF son equivalentes únicamente si sus representaciones del modelo de datos son las mismas. Esta definición de equivalencia permite algunas variaciones sintácticas en expresiones, sin tener por ello que alterar el significado. El modelo de datos básico consta de tres tipos de objetos:

● Recursos. Todas las cosas descritas por expresiones RDF se denominan recursos. Un recursos puede ser una página Web completa; tal como el documento HTML o una colección completa de páginas; p. ej. un sitio Web completo. Sin embargo, también puede ser un elemento que no se encuentre accesible de forma directa a través de la Web, como por ejemplo, un libro. De acuerdo a esto, podemos decir que un recurso es cualquier cosa que puede tener una URI, esto incluye todas las páginas web, todos los elementos individuales de cada documento XML y mucho más.

● Propiedades. Una propiedad es un aspecto específico, característica, atributo o relación utilizado para describir un recurso . Cada propiedad tiene un significado específico; define sus valores permitidos, los tipos de recursos que puede describir y sus relaciones con otras propiedades.

● Sentencias. Un recurso específico junto con una propiedad, más el valor de dicha propiedad para ese recurso, es lo que se denomina una sentencia RDF (RDF statement). Estas tres partes individuales de una sentencia se denominan sujeto, predicado y objeto. El objeto de una sentencia (es decir, el valor de la propiedad) puede ser otro recurso o pude ser un literal; es decir, un recurso (especificado por un URI) o una cadena simple de caracteres (string) u otros tipos de datos primitivos definidos por XML. Una sentencia es por ejemplo: "El autor de http://metadatos-xml-rdf.awardspace.com/rdf.html es Julio César Ayllón Bonet".

RDF esta cuidadosamente diseñado para tener las siguientes características:

● Independencia. Dado que una propiedad es un recurso, toda organización independiente o incluso cada persona puede inventarlas.

● Intercambio. Ya que las sentencias RDF se escriben en XML, pueden ser fácilmente usadas para intercambiar información.

71

● Escalabilidad. Las sentencias RDF son simples registros con tres campos (Recurso, propiedad, valor), por lo que son fáciles de manejar y de usar para buscar objetos incluso en volúmenes realmente grandes. La web ya es lo suficientemente grande y continúa creciendo. Es probable que tengamos en algún momento miles de millones de RDFs flotando a nuestro alrededor algún día. Por eso la escalabilidad es importante.

● Las propiedades son recursos. Las propiedades pueden tener sus propias propiedades y pueden ser encontradas y manipuladas como cualquier otro recurso. Esto es importante porque tendremos muchísimos recursos que manejar. Demasiados como para buscarlos uno por uno.

● Los valores pueden ser recursos. Por ejemplo, la mayoría de las páginas web podrían tener una propiedad llamada "home" que apunte al home del sitio. Por lo tanto los valores de sus propiedades que podrían incluir el titulo y autor de la pagina también tienen que incluir recursos.

● Las sentencias pueden ser recursos. Las sentencias también tienen propiedades. Dado que no hay un estándar para todos los recursos posibles, y dado que la web es demasiado grande como para que cada uno provea el suyo, tendremos que realizar búsquedas basadas en los metadatos de otras personas. Esto significa que querremos, dada una sentencia, como "el tema de esta página es monos", poder preguntar: "¿quién lo dice?", "¿cuándo lo dice?", “¿cómo lo dice?”, etc. Una forma útil de hacer esto es mediante metadatos, por ello las sentencias deben poder tener sus propias propiedades.

5.3. EJEMPLO DE UNA SENTENCIA RDFLos recursos se identifican por un identificador de recursos. Un identificador de

recursos es una URI más un identificador opcional de ancla Para simplificar los ejemplos, las propiedades de los recursos se referirán a través de un nombre simple. Vamos a considerar como un primer ejemplo la siguiente sentencia:

“Ora Lassila es el creador [autor] del recurso http://www.w3.org/Home/Lassila.”

Esta sentencia comprende las siguientes partes:

● Sujeto o recurso:”http://www.w3.org/Home/Lassila”

● Predicado o propiedad: Creador o autor

● Objeto o literal: “Ora Lassila”.

Podemos representar gráficamente la sentencia mediante un diagrama de grafos. En estos gráficos, los nodos (dibujados como óvalos) los representan recursos y los arcos representan las propiedades de dichos recursos. Los nodos, que representan cadenas de literales, pueden dibujarse como rectángulos. La sentencia citada anteriormente se representaría gráficamente como se muestra en la figura 22.

La dirección de la flecha es importante. El arco siempre empieza en el sujeto y apunta hacia el objeto de la sentencia. Este diagrama simple puede también interpretarse o leerse como "http://www.w3.org/Home/Lassila tiene como creador a Ora Lassila", o en general: "<sujeto> TIENE <predicado> <objeto>".

72

Figura 22. Modelo de grafos de una sentencia en RDF.

Imaginemos que queremos decir algo más sobre las características del creador de este recurso. Tal declaración, en el lenguaje natural, podría ser: “El individuo cuyo nombre es Ora Lassila, correo electrónico <lassila@w3.org>, es el creador de http://www.w3.org/Home/Lassila.”. La intención de esta frase es precisar el valor de la propiedad Creator (Creador) una entidad estructurada. En RDF tal entidad se representa como otro recurso.

La sentencia anterior no proporciona un nombre a ese recurso; es anónimo, por ello el gráfico a continuación lo representa como un óvalo vacío:

Figura 23. Modelo de grafos de un sentencia RDF más completa.

Este diagrama puede leerse: "http://www.w3.org/Home/Lassila tiene el creador cualquiera y este cualquiera tiene el nombre Ora Lassila y el correo electrónico lassila@w3.org". A la entidad estructurada de este ejemplo se le puede asignar un único identificador. El diseñador de la aplicación de la base de datos es quien de debe hacer la elección de tal identificador.

Continuando con el ejemplo, imaginemos que el identificador empleado se utiliza como único identificador para un recurso "persona". Las URIs que sirven como única clave para cada empleado (definido por la organización) podrían ser parecidas a: http://www.w3.org/staffId/85740. Ahora podemos escribir dos frases o sentencias:

“El individuo al que se refiere el identificador de empleado id 85740 se llama Ora Lassila y tiene la dirección de correo lassila@w3.org. Ese individuo creó el recurso

73

http://www.w3.org/Home/Lassila”

El modelo RDF para estas frases o sentencias es:

Figura 24. Modelo de grafos de una sentencia completa en RDF.

Obsérvese que este gráfico es idéntico al anterior, pero con la adición de una URI para el recurso que antes era anónimo. Desde el punto de vista de una segunda aplicación, que interrogue a este modelo, no hay distinción entre la sentencia hecha de forma individual y la sentencia realizada por partes.

5.4. SINTAXIS BÁSICA RDFEl modelo de datos RDF proporciona un marco abstracto y conceptual para definir y

utilizar metadatos, éste a su vez también necesita de una sintaxis concreta para crear e intercambiar metadatos. La especificación RDF utiliza el Lenguaje de Marcado eXtensible o XML (Extensible Markup Language) como sintaxis de intercambio, utilizando los “namespaces” de XML para asociar con precisión cada propiedad con el esquema que define dicha propiedad.

Vamos a explicar dos sintaxis XML utilizadas para codificar una instancia (objeto específico de una categoría) del modelo de datos. La primera de ellas, que se denomina “sintaxis serializada”, expresa las capacidades totales del modelo de datos de forma muy regular. Por otro lado, la “sintaxis abreviada”, incluye términos adicionales para proporcionar una forma más compacta de representación de un subconjunto del modelo de datos. Los intérpretes de RDF se han anticipado a implementar ambas sintaxis, la serializada completa y la abreviada. Así, los autores (creadores) de metadatos pueden mezclar ambas libremente.

5.4.1 SINTAXIS SERIALIZADA COMPLETA

Una sentencia, o declaración RDF, rara vez aparece sola; normalmente se darán juntas varias propiedades de un recurso. La sintaxis RDF XML se ha diseñado para dar cabida a

74

esto, agrupando múltiples sentencias, para un mismo recurso, en un elemento Description. El elemento Description denomina, mediante en un atributo about, el recurso para el cual se aplica cada una de las sentencias. Si el recurso no existe todavía, es decir, no tiene aun un identificador de recursos, el elemento Description puede proporcionar el identificador para el recurso usando el atributoID.

La sintaxis serializada RDF básica tiene los elementos que podemos ver en la siguiente lista:

● RDF: <rdf:RDF>description* </rdf:RDF>.

● description: <rdf:Description idAboutAttr? >propertyElt* </rdf:Description>.

● idAboutAttr: idAttr | aboutAttr.

● aboutAttr: about= URI-reference.

● idAttr: ID= Idsymbol.

● propertyElt: <propName >value </’ propName >|<propName resourceAttr/> .

● propName: Qname.

● value: description | string.

● resourceAttr: resource= URI-reference.

● Qname: NamespacePrefix : name.

● URI: reference string (una URI).

● IDsymbol: cualquier s´#mbolo permitido en XML.

● name: cualquier nombre permitido en XML.

● namespacePrefix: cualquier espacio de nombre permitido en XML.

● string: cualquier texto permitido en XML.

Pasamos a continuación a explicar brevemente los elementos más relevantes de la misma:

● El elemento RDF. Es un simple envoltorio que marca los límites en un documento XML, donde el contenido será definido como una instancia del modelo de datos RDF.

● El elemento Description. Contiene los elementos sobrantes que posibilitan la creación de sentencias en el objeto específico de la categoría del modelo. Se puede entender como un lugar donde mantener la identificación de un recuso descrito. Normalmente habrá más de una sentencia sobre un recurso, de manera que el elemento Description proporcione una forma de dar un nombre concreto a varias sentencias de una vez.

Cuando se especifica el atributo about con Description, la sentencia del elemento Description se referirá al recurso cuyo identificador determina el elemento about.

● El atributo About. Su valor se interpreta como una referencia en forma de URI. Para obtener el identificador del recurso correspondiente, lo que se hace es resolver la URI de forma absoluta. Si se incluye un fragmento identificador en la URI, el identificador de

75

recursos se refiere sólo y exclusivamente a la subcomponente del recurso que lo contiene (aboutAttr), mientras que el recurso se identificará con el correspondiente fragmento identificador que contiene dicho recurso (idAttr). Los valores para cada atributo identificador (idAttr) no deben repetirse en un mismo documento. Es importante tener en cuenta que tanto el “idAttr” como about pueden especificarse en un elemento Description, aunque no a le vez en el mismo elemento.

● El elemento propertyElt. Un mismo elemento Description puede contener más de un elemento “propertyElt” con el mismo nombre de propiedad, donde cada uno de estos propertyElt añaden un nuevo atributo al sujeto o predicado de la sentencia. Dentro del elemento propertyElt, el atributo “resource” especifica que otros recursos aparecen como valor de esta propiedad; es decir, el objeto de la sentencia es otro recurso identificado por una URI.

● El elemento Strings. Las cadenas deben cumplir con las reglas de formación de XML. En un XML convencional encontramos mecanismos de citación y disgregación que pueden usarse si la cadena de caracteres (string) contiene secuencias de caracteres que no cumplen las reglas de buena formación. Se hace necesario que las cadenas tengan una sintaxis adicional que especifique un contenido XML bien formado y que tenga un marcado que conlleve que éste no sea interpretado por RDF.

● El elemento Name. Los nombres de propiedad o “names” pueden asociarse con un esquema. Esto puede hacerse cualificando los nombres de los elementos a un prefijo de namespace que asocie con claridad la definición de propiedad con el esquema RDF correspondiente.

Veamos un ejemplo que nos ayude a clarificar todo los conceptos que hemos estado comentando anteriormente:

Figura 25. Código explicativo de la sintaxis básica serializada de RDF.

En este código podemos ver cómo describimos el objeto documentación. El namespace “d” se refiere a un prefijo específico, elegido por nosotros, de esta expresión RDF. Dicho prefijo está definido en una declaración XML del namespace del tipo xmlns:d="http://description.org/documentation”. Este tipo de declaración del namespace podría incluirse como un atributo XML en el elemento rdf:RDF, pero también puede incluirse con un elemento Description específico, o incluso como una expresión propertyElt concreta.

La URI del nombre del namespace, en la declaración del namespace, es un identificador unívoco para un esquema particular que la persona que define los metadatos utiliza para definir el uso de la propiedad (en este caso Creator).

Otros esquemas pueden definir igualmente la propiedad denominada Creator, ambas propiedades se diferenciarán gracias a sus identificadores de esquema (en este caso d). Hay que

76

1 <rdf:RDF>2 <rdf:Description about=”http://www.miweb.es/docs”>3 <d:Creator> Israel Rodríguez </d:Creator>4 </:rdf:Description>5 </rdf:RDF>

tener en cuenta también que un esquema, normalmente, define varias propiedades; esto permite que con una única declaración de namespace sea suficiente para crear un amplio vocabulario de propiedades que puedan usarse.

El documento XML completo, que contiene la descripción citada anteriormente, es el que podemos ver en la figura 26.

Figura 26. Código con declaración de esquemas RDF.

RDF no es algo estricto que sólo permita hacer las cosas de una única manera, todo lo contrario, RDF nos ofrece una gran diversidad de formas para representar una misma información dependiendo del enfoque que se quiera dar a los distintos esquemas. En los siguientes trozos de código podemos ver dos formas distintas de expresar lo que hemos visto en el código anterior.

Figura 27. Variante del código de la figura 25.

Figura 28. Variante del código de la figura 25.

La forma de condensar el código que observamos en esta última figura debe de evitarse siempre que la codificación RDF/XML se escriba a mano o con un editor de textos planos. Aunque estas codificaciones no son ambiguas, la posibilidad de error es mayor si los prefijos explícitos se usan de una forma consciente.

No debemos olvidar que, en un fragmento RDF/XML utilizado para ser insertado en otro documento, la declaración de todos los namespaces debe hacerse de tal forma que éstos sean completamente independientes.

5.4.2. SINTAXIS BÁSICA ABREVIADA

Aunque la sintaxis serializada muestra la estructura de un modelo RDF de una forma

77

1<?xml versión="1.0">2<rdf:RDF3 xmlns:rdf="http://www.w3.og/1999/02/22-rdf-syntax-ns#"4 xmlns:d="http://description.org/docs/">5 <rdf:Description about=”http://www.miweb.es/docs”>6 <d:Creator> Israel Rodríguez </d:Creator>7 </:rdf:Description>8 </rdf:RDF>

1<?xml versión="1.0">2<RDF3 xmlns:rdf="http://www.w3.og/1999/02/22-rdf-syntax-ns#"4 xmlns:d="http://description.org/docs/">5 <Description about=”http://www.miweb.es/docs”>6 <d:Creator> Israel Rodríguez </d:Creator>7 </Description>8 </RDF>

1<?xml versión="1.0">2<RDF xmlns:rdf="http://www.w3.og/1999/02/22-rdf-syntax-ns#">3 <Description about=”http://www.miweb.es/docs”>4 <d:Creator xmlns:d="http://description.org/docs/"> Israel Rodríguez </d:Creator>5 </:Description>6 </RDF>

más esclarecedora, normalmente la sintaxis que se utiliza es la compacta o abreviada. Esto se debe a que la sintaxis RDF permite que los documentos entiendan los llamados DTD (Document Type Definition), documentos XML bien estructurado que contienen las definiciones de los formatos de datos del modelo RDF.

Existen tres maneras de abreviar la sintaxis básica serializada:

● Utilizar propiedades no repetidas dentro de un elemento Description donde los valores de dichas propiedades son literales. Tratando un ejemplo similar al de las figuras anteriores (figuras 24 y 25), podemos abreviarlo de la forma (figura 26):

Figura 29. Código RDF abreviado utilizando propiedades no repetidas.

Podemos observar que el elemento Description tiene como atributo XML a la propiedad Creator. Esto permite que se pueda omitir la etiqueta final de Description debido a la sintaxis de elemento vacío de XML. Hay que tener en cuenta que a pesar de que estas dos expresiones RDF son equivalentes, los distintos motores de procesamiento las tratarán de forma diferente. En concreto, si ambas estuviesen embebidas en un documento HTML, el comportamiento por defecto de un navegador que no reconozca RDF será presentar los valores de las propiedades en el primer caso y en el segundo caso debería presentarse de forma no textual.

● Trabajar sobre elementos Description. Esta forma abreviada puede emplearse para sentencias específicas donde el objeto de la declaración es otro recurso. Para ello, el valor de cualquier propiedad del recurso deberá ser una cadena de caracteres. Esta es una transformación parecida a la realizada en XML nombrando distintos atributos, es decir, las propiedades del recurso en el Description anidado puede escribirse como XML del elemento propertyElt en el que se comprende el Description.

Para esclarecer este último punto, podemos ver la figura 27:

Figura 30. Código RDF abreviado con elementos Description.

Esta forma de representar los datos pretende enfocarse en el hecho de que se está describiendo dos recursos por separado; por un lado la persona y por otro el documento. El incoveniente de esta representación lo encontramos en que no queda claro que el recurso documento esté referenciado al recurso usuario. Como solución a este problema se presenta el siguiente código, donde no hay que dejar de tener el cuenta que el motor

78

1<rdf:RDF> 2 <rdf:Description about=”http://www.miweb.es/docs" d:Creator=" Israel Rodríguez"> 3 </RDF>

1 <rdf:RDF> 2 <rdf:Description about=”http://www.miweb.es/user/222/docs"> 3 <s:Creator rdf:resource=”http://www.miweb.es/user/222"> 4 <rdf:Description about=”http://www.miweb.es/user/222" 5 p:Name="Israel Rodríguez Ponce" 6 p:Email="isrrodpon@us.es" 7 </rdf:Description> 8 </s:Creator> 9 </rdf:Description> 10 </rdf:RDF>

que trate con ésta información no debe hacer diferencias entre uno y otro método.

Figura 31. Código RDF abreviado con elementos Description ( ejemplo refinado).

Utilizando esta segunda sintaxis abreviada, el elemento Description y las propiedades de las expresiones que contiene, pueden considerarse atributos del elemento Creator. (Ver figura 26).

Si usamos esta forma abreviada, el atributo about, del elemento anidado Description, se convierte en un atributo de resource en el elemento propertyElt, de igual forma que el recurso designado por la URI es, en ambos casos, el valor de la propiedad Creator. Es simplemente una cuestión de preferencia de la persona que asigna los metadatos. Desde el punto de vista del motor que los trate, todas producen los mismos modelos RDF.

Figura 32. Código RDF abreviado con elementos Description con sus atributos como parte del elemento Creator.

● Utilizar un elemento Description que tenga una propiedad type. En este caso, el tipo de recurso definido en el esquema que corresponde al valor de la propiedad type puede utilizarse como nombre del elemento. En el siguiente fragmento de código se puede ver como sería esta tercera forma básica de sintaxis RDF abreviada.

Figura 33. Código RDF abreviado trabajando con la propiedad type del elemento Description.

Los elementos de la sintaxis compacta son los mismos que los de la serializada, exceptuando los que podemos ver a continuación. Los dos primeros sustituyen a los que ya

79

1 <rdf:RDF> 2 <rdf:Description about=”http://www.miweb.es/user/222/docs"> 3 <s:Creator rdf:resource=”http://www.miweb.es/user/222"> 4 <rdf:Description about=”http://www.miweb.es/user/222"> 5 < p:Name> Israel Rodríguez Ponce </p:Name> 6 <p:Email> isrrodpon@us.es </p:Email> 7 </rdf:Description> 8 </s:Creator> 9 </rdf:Description> 10 </rdf:RDF>

1 <rdf:RDF> 2 <rdf:Description about=”http://www.miweb.es/user/222/docs"> 3 <s:Creator rdf:resource=”http://www.miweb.es/user/222"> 4 p:Name="Israel Rodríguez Ponce" 5 p:Email="isrrodpon@us.es"/> 6 </rdf:Description> 7 </rdf:RDF>

1 <rdf:RDF> 2 <rdf:Description about=”http://www.miweb.es/user/222/docs"> 3 <s:Creator> 4 <s:Person about=”http://www.miweb.es/user/222" 5 <p:Name>Israel Rodríguez Ponce</p:Name> 6 </s:Person> 7 </s:Creator> 8 </rdf:Description> 9 </rdf:RDF>

existían en la serializada y los otros dos se añaden a todos los demás.

● description: <rdf:Description idAboutAttr? PropAttr*/>|<rdf:Description idAboutAttr? >propAttr* >propertyElt* </rdf:Description>| typedNode.

● propertyElt: <propName >value </’ propName>|<propName resourceAttr? propAttr* />

● propAttr: propName= string.

● typedNode: <typeName idAboutAttr? propAttr*/>|<typeName idAboutAttr? propAttr* >property* </ typeName>.

5.5. ESQUEMA RDF (SCHEMA RDF O RDFs)Conociendo las normas básicas de la sintaxis RDF el siguiente paso es normalizar la

forma que se tiene de determinar los términos que serán utilizados en RDF. Con ello, se pretende que el lenguaje sea imparcial con un significado unívoco de los términos utilizados.

En lenguaje natural, usado por los humanos, al escribir un frase se pretende que las palabras transmitan un concepto con un significado inequívoco. Este significado es crucial para entender dicha frase y en el caso de RDF es fundamental para que el procesamiento del documento sea correcto. Es muy importante que tanto el escritor de una sentencia, como el lector, entiendan el mismo significado para los términos utilizados.

Para ser lo más preciso posible, se define el concepto schema RDF o RDFs. Explicándolo de una forma sencilla podemos decir que no es más que un diccionario que permite definir los términos que se van a usar en una sentencia, otorgando determinados significados.

Aunque podemos encontrar una gran variedad de formas de esquemas, RDF utiliza su propio estándar concreto (RDFs), que engloba las características más comunes y permite una mayor automatización de las tareas RDF. RDFs define ciertas clases que pueden representar casi cualquier elemento que deseemos, siendo descritas por recursos y propiedades tales como rdfs:Class, rdf:Resource y rdf:type, rdfs:subClassOf.

Por tanto, podemos decir que una clase es cualquier recurso que tenga un tipo (rdf:type) como propiedad y cuyo valor sea un recurso rdfs:Class. Un ejemplo de ello lo podemos ver en la siguiente figura.

Figura 34. Ejemplo declaración RDFschema .

Si nos fijamos bien en el código de la figura 34, podemos ver que aparece una etiqueta conocida como rdf:ID. Esta etiqueta nos permite identificar el recurso que queremos definir. En

80

1 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 2 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> 3 <rdf:Description rdf:ID=”Documentation"> 4 <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> 5 </rdf:Description> 6 <rdf:Description rdf:ID="DocumentSection"> 7 <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/> 8 <rdfs:subClassof rdf:resource0"#Documentation"/> 9 <rdf:Description> 10 </rdf:RDF>

RDFs, las propiedades se describen usando la clase rdfs:Property, definiendo en las mismas los elementos rdfs:domain, rdfs:range y rdfs:subPropertyOf. Cabe destacar la posibilidad de tener clases distintas con una misma propiedad. En la siguiente lista podemos ver la descripción de los elementos de las propiedades del RDFSchema.

● rdfs:range . Indica que los valores de la propiedad son instancias de algún otro tipo de dato.

● rdfs:domain . Se usa para indicar que una propiedad es aplicada a la clase en concreto.

● rdfs:subPropertyOf. Describe la especialización entre dos propiedades. (Similar a la propiedad subClassOf ).

Muchas veces, el valor de una propiedad es algo que tiene información contextual adicional que se considera parte de dicho valor. Es decir, es necesario distinguir los valores de las propiedades (por ejemplo; unidades de medida, precios en distintas divisas, etc.) Para poder representar este tipo de información tenemos lo que se denomina valor de propiedad cualificada.

6. EL ESTÁNDAR DE METADATOS MPEG-7

6.1 INTRODUCCIÓNEl estándar de contenidos multimedia, o MPEG-7, es un estándar internacional de la

ISO/IEC desarrollado por el grupo MPEG (Moving Picture Experts Group). El grupo MEPG ya ha desarrollado otros estándares tales como MPEG-1, MPEG-2 y MPEG-4. MPEG-1 y MPEG-2. Estos estándares han permitido la implementación de productos tan conocidos y aceptados como el Vídeo CD, el MP3, el DVD o la televisión digital.

Hace años, el acceso a contenidos multimedia solía ser una tarea que no entrañaba ningún problema. Esto se debía a la manera de acceder a los contenidos y a que existían pocos contenidos multimedia disponibles. No se tenía una necesidad de clasificar los contenidos multimedia. El problema apareció con la revolución digital, donde una enorme y creciente cantidad de contenidos audiovisuales se pusieron a disposición de todo el mundo, gracias, principalmente, a la enorme difusión de Internet.

En esta nueva situación, el valor de la información empieza a depender de cómo se accede a ella. Es decir, si tenemos una situación en la que el acceso es muy complejo debido a la gran cantidad de información y de fuentes que la distribuyen, es probable, que el consumo de recursos sea tal, que no sea rentable acceder a dicha información. De esta manera, el valor de la información no dependerá solamente de la información en sí misma, sino también de la facilidad para ser encontrada, recuperada y filtrada.

La tendencia es clara, en los próximos años los usuarios tendrán que enfrentarse a una cantidad tal de contenidos disponibles, y a través de un número tan elevado de fuentes, que el acceso eficiente y preciso es algo, sin duda, de gran valor. Esto, junto con una identificación y administración eficiente, se está volviendo cada vez una tarea cada vez más complicada, tanto a nivel profesional como personal.

81

MPEG-7 pretende solucionar esta necesidad. El estándar MPEG-7, conocido como “Interfaz de Descripción de Contenido Multimedia”, proporciona un amplio conjunto de herramientas estandarizadas para describir contenidos multimedia, tanto para usuarios humanos como para sistemas automáticos que procesen información audiovisual. Estas herramientas de descripción, conocidas como “Description Tools”, la forman metadatos junto con su estructura y las relaciones, todo ello definido en el estándar mediante Descriptores (D) y Esquemas de Descripción (DS). Ambos sirven para crear descripciones que serán la base de aplicaciones que permitan este necesario acceso eficiente a un contenido multimedia. Es una tarea complicada dado el amplio espectro de requisitos y aplicaciones multimedia que pretende abarcar, así como por el gran número de características, audiovisuales de importancia, existentes en estos contextos.

6.2. OBJETIVO Y ALCANCE DE MPEG-7Puesto que cada día más y más información audiovisual está siendo puesta a nuestra

disposición , los contenidos multimedia están alcanzando un papel de extrema importancia en las sociedades modernas. Información que está disponible desde un número creciente de fuentes: imágenes, gráficos, modelos 3D, audio, habla, vídeo, etc.

Esta información audiovisual generalmente es consumida directamente por el ser humano, aunque hay un creciente número de casos en los que es creada, intercambiada, recuperada y rehusada por sistemas computacionales. Tal es el caso de la comprensión y reconocimiento de imágenes (vigilancia, visión artificial, cámaras inteligentes, etc.) o la conversión de medio (de voz a texto, de imagen a voz, etc.). La necesidad de un procesado posterior de un contenido audiovisual hace necesario el desarrollo de nuevas formas de representación que vayan más allá de la simple representación basada en forma de onda (waveform) o incluso basada en objetos (como se definía en el estándar MPEG-4).

Hoy por hoy, es necesario que se permita un cierto grado de interpretación del significado de la información. MPEG-7 es un estándar que soportará estos requisitos operacionales, requisitos que se aplican tanto para aplicaciones de tiempo real como in diferido. (MPEG-7 no estandariza ni evalúa dichas aplicaciones).

MPEG empezó a trabajar en 1996 con el objetivo de crear un estándar que permitiera solucionar los problemas descritos anteriormente. La llegada de MPEG-7 abre un nuevo camino, al tratarse de un estándar de metadatos que va a representar información sobre los contenidos (“bits sobre bits” o “datos sobre datos”, como los hemos estado denominando a lo largo de todo el documento). Las herramientas de descripción que ofrece MPEG-7 son, por tanto, independientes de cómo será almacenado o codificado el contenido (se puede trabajar con señales analógicas o digitales). MPEG-7 parte de la base de que existe una representación (estandarizada o no) del contenido y se encarga de describir todo lo relacionado con él.

Debido a que las posibilidades que existentes para describir información son casi infinitas, el estándar debe barrer diferentes niveles de abstracción. Estos van, desde características de bajo nivel (en relación directa con el vídeo o el audio, por ejemplo) que pueden ser extraídas de forma automática, hasta altos niveles (descripciones de tipo semántico) donde se

82

necesitan personas para su extracción, ya que su automatización resultaría mucho más costosa. Se observa que la información textual para los descriptores es muy útil para el caso de descripciones de tipo semántico, pero el estándar no quiere estancarse en este único modo, y propone hacer uso de todo tipo de información (histogramas, fragmentos de audio, etc.) para trabajar con el contenido.

MPEG-7 no se centra en una parcela determinada de la información multimedia o de una aplicación, como ocurre con otros estándares que hemos visto anteriormente, caso de Dublin Core, todo lo contrario, su rango de actuación incluye multitud de aplicaciones en entornos diferentes. Esto conlleva la necesidad de ofrecer un marco de trabajo flexible y variable para describir datos multimedia, de forma que MPEG-7, no defina un sistema monolítico para describir el contenido sino un conjunto de métodos y herramientas para las diferentes posibilidades de descripción de un mismo contenido. La idea es conseguir que MPEG-7 sea lo más genérico posible.

MPEG-7 utiliza XML Schema como lenguaje para la representación textual del contenido, lo cuál le permite ser un estándar flexible, con facilidad para aumentar las herramientas de descripción ya existentes. Para poder dar al estándar mayores funcionalidades no se utiliza XML Schema puro sino que se han añadido algunas extensiones de las que éste carece.

Los elementos principales del estándar MPEG-7 son:

● Descriptores (D): son las representaciones de características que definen la sintaxis y la semántica de cada representación característica. Estas representaciones no serán más que un determinado conjunto de metadatos MPEG-7.

● Esquemas de Descripción (DS): especifican la estructura y semántica de las relaciones entre sus componentes. Estos componentes pueden ser tanto D’s como DS’s.

● Lenguaje de Definición de Descripciones (DDL): proporciona las herramientas para permitir la creación de nuevos DS’s y D’s. También permite la extensión y modificación de los DS’s existentes.

● Herramientas del sistema: permiten el multiplexado de diferentes descripciones así como la sincronización de las mismas con el contenido. Se ocupan de los mecanismos de transmisión y de representaciones codificadas (tanto textuales como binarias) para almacenarlas y transmitirlas de forma eficiente. También incluyen los procesos de gestión y protección de la propiedad intelectual, cuya relación se puede observar en la Figura X.

Figura 35. Relaciones entre los diferentes elementos de MPEG-7.

83

Los DS’s y D’s describen el contenido desde distintos puntos de vista definidos por MPEG-7:

● Creación y Producción: elementos relacionados con la creación y la producción del contenido, tales como: título, creador, clasificación, propósito de la creación, etc. La mayoría de esta información no se puede extraer directamente del contenido.

● Uso: elementos que describen la información acerca del uso del contenido, como por ejemplo: los derechos de acceso al contenido, información financiera, etc. Este tipo de información está sujeta a posibles variaciones a lo largo de la vida del contenido audiovisual.

● Medio: estos elementos describen como se almacena el contenido: formato de almacenamiento o codificación del contenido audiovisual entre otros.

● Aspectos Estructurales: contiene los elementos de descripción de la estructura en torno a segmentos que representan componentes físicos espaciales, temporales o espacio-temporales del contenido audiovisual. Cada uno de estos segmentos puede estar descrito por características básicas como el color, la textura o algún otro tipo de información semántica.

● Aspectos Conceptuales: describe el contenido audiovisual a través de sus características conceptuales.

● Otros Aspectos: aparte de los aspectos mencionados, los cuales están directamente relacionados con la descripción del contenidos, MPEG-7 estandariza herramientas de descripción que ofrecen soporte a determinadas aplicaciones. Estos aspectos son Navegación y Acceso, Organización del Contenido, e Interacción del usuario.

En la siguiente figura podemos observar el diagrama de bloques de una posible cadena de procesado en MPEG-7, donde se muestra el alcance que tiene dicho estándar.

Figura 36. Alcance de MPEG-7.

Comentamos, en primer lugar, que la extracción de las características de un contenido audiovisual (análisis), puede ser automática o manual. Una vez tenemos las características descriptivas, pasamos a la descripción propiamente dicha del contenido, para acabar en el motor de búsqueda (una aplicación).

Aunque es muy útil la extracción automática o semiautomática de características, ésta no queda dentro del alcance del estándar ya que no es necesario para permitir la

84

interoperabilidad, dejando así que sea la industria quien proponga soluciones. Lo mismo sucede con los motores de búsqueda, agentes de filtrado o cualquier aplicación que haga uso de las descripciones, esto no se estandarizan, dejando que sea la industria quien promueva la competición de soluciones.

MPEG-7 pretende que se presenten soluciones para la extracción y la búsqueda de características, pero sin querer adoptar ninguna de ellas como parte del propio estándar. Se limita a estandarizar la forma en que se codifica la descripción del contenido. El uso, o la manera de generarlo, queda abierto a cualquiera, potenciando así la competición entre diferentes soluciones.

Un ejemplo de una posible la cadena del proceso, descrito anteriormente, se representa en la siguiente figura. En ella, las formas rectangulares representan herramientas funcionales, como codificación o descodificación, mientras que las circulares representan elementos estáticos, tales como las descripciones. Los rectángulos de fondo gris son los elementos normativos que se acaban de definir. En esta figura también se incluyen elementos que no están incluidos en el estándar, como puede ser el proceso de extracción o el sistema de búsqueda, aunque sí estén incluidos en el software de referencia.

Figura 37. Representación de una aplicación en MPEG-7.

Por último, vamos a nombrar algunas de las múltiples áreas en las cuales MPEG-7 puede dar lugar a un amplio rango de aplicaciones. Puesto que todas las áreas en las cuales encontremos contenidos multimedia se podrán beneficiar del uso de este estándar. Algunas de estas posibles aplicaciones son:

● Comercio electrónico (p. ej.: anuncios personalizados, catálogos en línea, directorios de tiendas electrónicas).

● Control remoto (p. ej.: cartografía, ecología, gestión de recursos naturales).

85

● Edición multimedia (servicios de noticias electrónicas personalizado, etc.).

● Educación (almacén de cursos multimedia, búsqueda multimedia para material de ayuda, etc.).

● Entretenimiento (p. ej.: sistemas para gestión de colecciones multimedia).

● Librerías digitales (p. ej.: catálogos de imágenes, diccionarios musicales, archivos de películas y radio).

● Periodismo (búsqueda de discurso de una persona usando su nombre, su voz, su cara, etc.).

● Selección de canales de difusión (p. ej.: canales de radio, de televisión).

● Servicios de cultura (museos de historia, galerías de arte, etc.).

● Servicios de directorio multimedia (p. ej.: páginas amarillas, información a turistas, sistemas de información geográfica).

● Servicios de investigación (p. ej.: reconocimiento de características humanas, medicina forense).

● Vigilancia (control del tráfico, transporte de superficie, pruebas no destructivas en lugares hostiles).

6.3. PARTES EN LAS QUE SE DIVIDE MPEG-7El estándar ISO/IEC 15938 está formado por las siguientes partes:

● MPEG-7 Systems: arquitectura del estándar y herramientas necesarias para preparar: las descripciones de MPEG-7, su transporte y un almacenamiento eficiente. También se ocupa de conseguir la sincronización entre contenido y descripciones. Otro aspecto que engloba son las herramientas relacionadas con la gestión y protección de la propiedad intelectual.

● MPEG-7 Description Definition Language: lenguaje para definir nuevos Dss, aunque también dá la posibilidad de describir, de forma eventual, nuevos Ds. Está basado en el XML Schema Language (XSL), aunque necesita de ciertas extensiones específicas para MPEG-7 ya que no fue diseñado para describir material audiovisual.

● MPEG-7 Audio: proporciona estructuras para describir material sonoro. En ellas se tiene un conjunto para de descriptores de bajo nivel (para características espectrales, temporales, etc), y otro para herramientas de alto nivel (que incluye herramientas para el reconocimiento de sonidos e indexación, la descripción del timbre de instrumentos, el habla, y el audio)

● MPEG-7 Visual: estructuras básicas y descriptores que cubren las siguientes características visuales básicas: color, textura, forma, movimiento, localización y reconocimiento facial. Cada categoría cuenta con un descriptor elemental y específico.

● MPEG-7 Multimedia Description Schemes: elementos (DSs y Ds) que describen

86

información genérica, es decir, que no es, ni puramente visual, ni de audio.

● MPEG-7 Reference Software - the eXperimentation Model: es una plataforma de simulación para el uso de descriptores (Ds), esquemas de descripción (Description Schemes or DSs), esquemas de codificación (Coding Schemes or CSs) y de lenguajes de definición de descripciones (Data Definition Language or DDL). Además de componentes normativos, la plataforma de simulación necesita también otros componentes no normativos, y que esencialmente ejecutan algunos procedimientos sobre las estructuras de datos. Las estructuras de datos y el código de los procedimientos forman las aplicaciones. Las aplicaciones XM están divididas en dos tipos: las aplicaciones servidoras (extracción) y las aplicaciones cliente (búsqueda, filtrado y/o transcodificación).

● MPEG-7 Conformance Testing: guía con procedimientos para comprobar que las implementaciones de MPEG-7 se ajustan a las normas establecidas (en desarrollo, en fase FDIS).

● MPEG-7 Extraction and use of the descriptions: material informativo (a modo de informe técnico) sobre la extracción y uso de algunas de las herramientas de descripción.

● MPEG-7 Profiles: recoge distintos perfiles y niveles estandarizados para MPEG-7, especificados a través de las partes del estándar ISO/IEC 15938. Mientras todas las partes son potencialmente candidatas para perfiles, los perfiles actuales se concentran en las partes Description Definition Language [ISO/IEC 15938-2], Visual [ISO/IEC 15938-3], Audio [ISO/IEC 15938-4], Multimedia Description Schemes [ISO/IEC 15938-5]. Todas están basadas en Schema Definition [ISO/IEC 15938-10].

● MPEG-7 Schema Definition: recoge todos los esquemas MPEG-7, reuniéndolos desde diferentes estándares.

● MPEG-7 Profiles Schema Definition: recoge los esquemas de los perfiles MPEG-7.

A parte de estos documentos ya publicados, existen correcciones de algunas de las partes de MPEG-7, y que se encuentran en diferentes fases de desarrollo:

● MPEG-7 Part 1: Systems AMENDMENT 1: System Extensions.

● MPEG-7 Part 3: Visual AMENDMENT 1: Visual Extensions.

● MPEG-7 Part 4: Audio AMENDMENT 1: Audio Extensions.

● MPEG-7 Part 5: Multimedia Description Schemes AMENDMENT 1: Multimedia Description Schemes Extensions.

● MPEG-7 Part 6: Reference Software AMENDMENT 1: Reference Software Extensions.

● MPEG-7 Part 7: Conformance Testing AMENDMENT 1: Conformance Testing Software Extensions.

87

6.4. MDS DE MPEG-7 (ESQUEMAS DE DESCRIPCIONES MULTIMEDIA)Anteriormente, hemos comentado que uno de los elementos fundamentales del

estándar MPEG-7 son los llamados DS´s, que están a su vez constituidos tanto por otros DS´s como por D´s. Ahora, vamos a pasar a comentar los DS´s genéricos que no se refieren ni al audio ni al video del contenido multimedia. Los D’s se utilizan para describir los siguientes tipos de información: MPEG-7

● Características audiovisuales de bajo nivel, como son el color, la textura, el movimiento, la energía, etc.

● Características de alto nivel de objetos semánticos, eventos y conceptos abstractos.

● Procesos de gestión del contenido.

● Información sobre el contenido.

En principio, la gran mayoría de los D´s utilizados para describir características de bajo nivel podrán ser extraídos de los contenidos de una forma automática. Por el contrario, se hará necesaria la intervención de un agente humano para extraer los D´s de alto nivel. En cuando a los DS’s de MPEG-7, podemos decir que están clasificados en tres grandes grupos: los que pertenecen a audio, los que pertenecen al dominio visual, y los que se agrupan en torno a la descripción genérica de datos multimedia.

En este último grupo se describen los metadatos relacionados con la creación, producción, uso y gestión de los datos multimedia; así como el contenido multimedia a distintos niveles de abstracción (incluyendo estructura de la señal, características modelos y semántica). Este grupo describirá todo tipo de información multimedia (datos visuales, textuales o sonoros), mientras que los D’s específicos, como son color, textura, forma, melodía, etc. pertenecen a los DS’s del dominio visual o de audio. Como ocurría con los D’s que sirven para describir características de bajo nivel, la instanciación de los DS’s puede hacerse en determinadas ocasiones de una forma automática, aunque por desgracia, la mayoría de las veces se hará manualmente.

Los DMS utilizados en MPEG-7 se dividen en seis partes:

1. Elementos básicos y herramientas

2. Descripción del contenido.

3. Gestión del contenido.

4. Organización del contenido.

5. Navegación y acceso.

6. Interacción con el usuario.

En la figura 38 que se muestra a continuación observamos gráficamente esta organización:

88

Figura 38. Resumen de los Esquemas de Descripción de Multimedia.

Pasaremos de forma más detallada a analizar cada uno de los elementos que componen un DMS de MPEG-7.

6.4.1. ELEMENTOS BÁSICOS DE UN DMS

La especificación de los MDS’s define un gran número de elementos básicos que se usan como constructores fundamentales en la definición de muchos de los DS’s de MPEG-7. Muchos de los elementos básicos ofrecen tipos de datos específicos y estructuras matemáticas, tales como vectores, matrices e histogramas, que son de gran utilidad para la descripción del contenido multimedia.

También se consideran como elementos básicos aquellos que relacionan ficheros de datos diferentes y localizan segmentos, regiones, etc. Estos elementos cubren la mayoría de las necesidades que aparecen en la descripción de contenidos multimedia, tales como, el tiempo, los lugares, las personas, los grupos, las organizaciones o varios tipos de anotaciones de tipo textual. Se pueden distinguir dos grandes grupos en estos elementos básicos, los cuales son utilizados por la mayoría de DS’s de MPEG-7:

1. Información temporal. Los DS’s que describen el tiempo se basan en el estándar ISO8601, el cual también ha sido adoptado por el lenguaje XML Schema (usado como base para el DDL). Los DS’s de tiempo representan la información temporal del contenido

89

(“streams” de los datos) o de lo que éste representa. MPEG-7 extiende esta especificación (ISO 8601) con el objeto de describir también el tiempo a nivel de muestras de la codificación del contenido multimedia, como puede ser cierta cantidad de periodos del muestreo digital.

2. Anotación textual. Los DS’s y D’s que sirven para hacer anotaciones textuales también son componentes importantes de otros muchos DS’s. MPEG-7 aporta una serie de construcciones básicas para ésta, incluyendo texto libre (palabras clave, frases), texto estructurado (texto y reglas), y anotación estructurada relacional (texto estructurado y relaciones). Con este bloque se pretende abarcar un amplio rango de funcionalidades de descripción textual.

La especificación de los MDS´s también ha definido un conjunto de Herramientas de Esquema que facilitan la creación y agrupación de descripciones MPEG-7. Estas herramientas consisten en un conjunto de elementos agrupados en distintos tipos: elementos base (base), elementos raíz (root), elementos de nivel superior (top-level) y herramientas de empaquetado (packages). Los elementos base son elementos abstractos que definen la jerarquía de las descripciones. Los elementos raíz, sobre los que se definen en las descripciones MPEG-7, permiten la creación de fragmentos o documentos XML según MPEG-7. Los elementos de nivel superior, inmediatamente inferiores en la jerarquía a los elementos raíz, organizan los DS’s con los que se está trabajando en ese momento para tareas completamente específicas orientadas a la descripción del contenido, como pueden ser:

1. Describir una imagen, vídeo, audio o contenido multimedia.

2. Crear colecciones.

3. Describir preferencias usuarios.

4. Mostrar la semántica.

Las herramientas de agrupación se utilizan para asociar ciertos componentes de los DS’s con determinadas carpetas o grupos. Estos grupos son útiles para organizar y trasladar la estructura y los tipos de información de descripciones MPEG-7 a motores de búsqueda ya existentes con GUI’s (Graphic User Interfaces) propietarios no basados en un modelo de metadatos MPEG-7. Actúan como traductores/adaptadores de metadatos de diversos modelos.

6.4.2. LA GESTIÓN DE CONTENIDOS

MPEG-7 ofrece DS’s para la descripción de diferentes aspectos de la creación, producción, codificación, almacenamiento, formatos de archivos y uso de los contenidos multimedia. Estos son los diferentes grupos de DS´s y sus funcionalidades:

● Creation Information: metadatos que se encargan de describir la creación y clasificación de un contenido multimedia ademas de otros materiales relacionados con ese contenido. Tiene tres grandes componentes: el primero se llama Creation, y ofrece herramientas de descripción para el título (puede ser textual o algún tipo de contenido multimedia) y la información sobre la creación del contenido (autores,lugares y fechas de la creación). El siguiente es Classification, que describe como se clasifica el material multimedia en

90

categorías tales como el género, tema, propósito, lenguaje, etc. También ofrece herramientas para describir aspectos como la clasificación por edades. Finalmente, está Related Material, que describe si existe algún otro tipo de material multimedia relacionado con el contenido descrito.

● Usage Information: metadatos que describen el uso que se le puede dar a un contenido multimedia (derechos de uso, disponibilidad e información financiera). La información sobre los derechos no está explícitamente incluida en la descripción MPEG-7, sin embargo, hay enlaces a los dueños de los derechos y a más información relacionada con la gestión y protección de los mismos. Existen cuatro grandes componentes en este grupo: Rights, que da referencias a los propietarios de los derechos o información relacionada, bajo la forma de identificadores unívocos gestionados por autoridades externas. Con ello se pretende que las descripciones den acceso a información sobre el dueño de los derechos sin entrar en negociaciones previas. Availability y Usage Record, ofrecen información relacionada con la disponibilidad y el uso pasado del contenido (difusión, demanda de entrega, etc.). Por último, Financial, describe la información sobre el coste de la producción y los ingresos resultantes de su uso. Todos estos datos suelen variar con el tiempo por lo que están sujetos al cambio durante la existencia del contenido multimedia.

● Media Information: metadatos que describen información sobre el almacenamiento del contenido, la compresión, codificación y formato de los datos. El componente Media Identification identifica una entidad que tiene al menos una copia original (master), ésta es la fuente dónde se producen diferentes instancias del contenido audiovisual. Las instancias son versiones del original, o de otros perfiles (las copias digitales son perfectas), a diferentes formatos de codificación, almacenamiento o entrega. Media Profile describe individualmente cada una de las copias por medio de sus parámetros de codificación, información y localización del almacenamiento.

6.4.3. DESCRIPCIÓN DEL CONTENIDO

Se utilizan DS’s que describen las estructuras (regiones, cuadros de vídeo y segmentos de audio) y la semántica (objetos, eventos y nociones abstractas) del contenido multimedia. Estos dos grupos de DS´s tienen las siguientes funcionalidades:

● Aspectos estructurales: describen el contenido multimedia desde el punto de vista de la estructura. Estos DS’s se organizan en torno a un Segment, que representa las características espaciales y temporales de un contenido multimedia. El Segment puede organizarse dentro de una estructura jerárquica para producir una tabla de contenidos que permita el acceso, o indexado, del contenido al hacer búsquedas. Los segmentos se describen utilizando DS’s (anotaciones textuales) y D’s de la parte de audio y vídeo.

● Aspectos conceptuales: describen el contenido multimedia desde el punto de vista de la semántica del mundo real y las nociones conceptuales. Incluyen entidades como: objetos, eventos, conceptos abstractos y relaciones.

Los aspectos conceptuales y estructurales se encuentran relacionados por un conjunto de enlaces que permiten al contenido multimedia ser descrito desde el punto de vista de ambos

91

aspectos. Los enlaces relacionan diferentes conceptos semánticos con las instancias del contenido que se encuentra descrito en los segmentos. Muchos de los DS’s usados para la descripción y gestión del contenido están unidos, incluyéndose mutuamente en sus respectivas descripciones. Por ejemplo, podemos adjuntar en un segmento información sobre el uso, creación y producción del contenido.

6.4.4. ORGANIZACIÓN DE LOS CONTENIDOS MULTIMEDIA

MPEG-7 ofrece DS’s que permiten organizar y formar colecciones de contenidos multimedia. El DS Collection organiza las colecciones de contenidos, segmentos, eventos y/o objetos. Permite que cada colección sea descrita como un todo basándose en propiedades comunes entre todos los contenidos. En particular, diferentes modelos y estadísticas se pueden especificar para caracterizar los valores de los atributos de las colecciones.

6.4.5. NAVEGACIÓN Y ACCESO A UN CONTENIDO

También encontramos DS’s para facilitar la navegación y la obtención de un contenido multimedia. Esto se consigue definiendo resúmenes, particiones, descomposiciones y variaciones del material.

● Summaries: Ofrecen breves resúmenes del contenido multimedia para permitir el descubrimiento, navegación, visualización y audición del contenido multimedia. Summary incluye dos tipos de navegación: jerárquica y secuencial. En el modo jerárquico la información se organiza en niveles que describen el contenido multimedia con niveles diferentes de detalle. En general, los niveles más cercanos al inicial (root) dan resúmenes más generales, y los más alejados, resúmenes más detallados. El resumen secuencial da muestras de vídeo o una secuencia de imágenes, posiblemente sincronizadas con audio, que componen una presentación o visualización rápida.

● Views, Partitions and Decompositions: Describen diferentes descomposiciones de señales multimedia en el espacio, el tiempo y la frecuencia. Pueden ser usadas para describir diferentes perfiles de los datos multimedia, importantes para el acceso a múltiples resoluciones y para la obtención progresiva del contenido multimedia.

● Variations: Dan información sobre las diferentes variaciones posibles en los contenidos. Ofrecen resúmenes, versiones escaladas, comprimidas y a baja resolución; y versiones con diferentes idiomas y modalidades (audio, vídeo, imagen, texto, etc.). Una de sus principales funcionalidades es la selección de la variación más apropiada de un contenido multimedia que pueda, si es necesario, sustituir al original. El fin que se persigue es adaptar las diferentes posibilidades de los terminales, redes o preferencias de usuario.

6.4.6. ITERACIÓN CON EL USUARIO

El último conjunto de herramientas de descripción se encarga de la interacción con el usuario. El elemento User Preference describe las preferencias del usuario que está haciendo uso

92

del material multimedia. Esto permite, por ejemplo, emparejar las preferencias y la descripción del contenido para facilitar la personalización del acceso, presentación y uso de la información audiovisual. El otro elemento, que contiene información sobre la interacción con el usuario, es Usage History, en el que se registran las acciones que lleva a cabo el usuario dentro del sistema.

7. EL ESTÁNDAR DE METADATOS TV-ANYTIME

7.1. ¿QUÉ ES EL TVA FORUM?“TV-Anytime Forum” es una asociación de organizaciones cuyo objetivo, basándose

en el mercado de masas, es desarrollar especificaciones que permitan el almacenamiento digital de servicios audiovisuales, o de otro tipo, en plataformas de usuario. La asociación está constituida por más de 60 miembros representantes de una gran variedad de industrias: emisoras de televisión, emisores por Internet, propietarios de contenidos, proveedores de servicios, fabricantes de consumibles electrónicos, fabricantes de equipos profesionales, fabricantes de componentes y vendedores de software, entre otros. La mayoría de los miembros proceden de Europa (BBC, BSkyB, BT, France Telecom, Nokia, Philips, EBU), Ásia (Daewoo, Hakuhodo, KETI, Matsushita Electric Industrial, JVC, Toshiba, Mitsubishi Electric) y algunos de Estados Unidos, como son los casos de Motorola, Microsoft y Walt Disney Television.

El TV-Anytime Forum se fundó marcándose cuatro objetivos fundamentales:

1. Definir especificaciones que permitan a las aplicaciones explotar el almacenamiento local en plataformas electrónicas de usuario.

2. El foro es independiente de la red con respecto a los medios para la distribución de contenidos a los equipos electrónicos de consumidor.

3. Desarrollar especificaciones para sistemas compatibles e integrados, desde los creadores/proveedores de contenidos hasta los consumidores, pasando por los proveedores de servicios.

4. Especificar las estructuras de seguridad necesarias para proteger los intereses de todas las partes involucradas.

Para la realización de dichos objetivos se crearon a su vez cuatro grupos de trabajo:

● Modelos de negocio. Este grupo trabaja bajo la premisa de que ningún sistema puede ser desarrollado sin imaginar y documentar, en primer lugar, todas las maneras, presentes y futuras, en las que dicho sistema podría ser usado. En la industria existe un amplio abanico de modelos de negocio. Para abarcarlos todos, este grupo se encarga de desarrollar las características y funcionalidades básicas necesarias en cada uno de ellos. Dichas características, y los escenarios que las acompañan, son transmitidas a los demás grupos relevantes con el objetivo de que sean comprobados para poder desarrollar las especificaciones adecuadas. A mediados de 2005 ya habían sido desarrollados modelos para algunos de los agentes clave, tales como: consumidores, proveedores de contenidos y servicios, anunciantes o fabricantes de equipos. El siguiente paso del grupo consiste en

93

buscar las diferentes formas de promover en la industria de los medios la adopción de TV-Anytime.

● Sistemas, interfaces de transportes y referenciación del contenido. Este grupo de trabajo es responsable de la arquitectura y consistencia del sistema TV-Anytime. Su principal objetivo es asegurar que el sistema de trabajo de TV-Anytime pueda ser construido a partir de sus propias herramientas. Entre las directivas del grupo también figura la definición de los requerimientos necesarios en la capa de transporte para el correcto funcionamiento del sistema. Dichos requerimientos permitirán a organizaciones como DVB, ATSC, ARIB y otras, implementar TV-Anytime en sus entornos.

En cuanto a la referenciación de contenido, el principal objetivo es conseguir una instancia específica de un contenido específico. Por ejemplo, si un usuario quisiera grabar una serie con un PVR (Personal Video Recorder), debería saber el momento en que ésta va a ser emitida para poder programarlo. Esto puede ser un problema ya que el usuario puede desconocer este dato y, además, la fecha y hora de emisión podría variar de un capítulo a otro.

Para dotar al usuario de esta capacidad se necesita poder referenciar el contenido independientemente de la localización de éste, ya sea un canal de difusión particular en un día y hora determinados, un servidor de ficheros conectado a Internet o cualquier otro. La especificación de TV-Anytime sobre referenciación de contenidos (TV-Anytime Content Referencing Specification) proporciona una referencia independiente de la localización, llamada CRID, y especifica el proceso por el cual este CRID ubica el tiempo y la localización donde pueden ser encontrados los contenidos deseados. Esta especificación excede el alcance del proyecto, por lo que no va a ser comentada en profundidad.

● Gestión de derechos y protección. El objetivo de este grupo es desarrollar estándares que permitan ofrecer una garantía de los derechos de la información distribuida hasta los PVR. Dentro de este objetivo se incluye la definición de interfaces estandarizadas que permitan, de forma legal, el acceso condicional y los sistemas de protección de contenidos. Para servir las necesidades de todo el espectro de proveedores de contenidos, desde servicios públicos de radiodifusión hasta distribuidores comerciales, es necesario un amplio rango de protección de contenidos y características de acceso, y además, es también necesario permitir la incorporación de servicios de valor añadido a la cadena de distribución.

● Metadatos TV-Anytime. Este grupo de trabajo se encarga de desarrollar una especificación de “Metadatos” de TV-Anytime. Los metadatos son descriptores que se utilizan, por ejemplo, en las Guías de Programación Electrónicas (EPG) o en las páginas Web, para describir los contenidos.

7.2. INTRODUCCIÓN AL ESTÁNDAR DE METADATOS TVAEl estándar de metadatos de TV-Anytime esta siendo adaptado para ser usados por

parte del DVB Consortium (Digital Video Broadcasting Consotium), en Europa, el ARIB (Association of Radio Industries and Business), en Japón y el ATSC (Advanced Television

94

System Commitee) en Estados unidos. El objetivo es la creación de un grupo de trabajo que desarrolle un estándar de metadatos que permita:

1. Que el consumidor, o unos agentes inteligentes, puedan buscar y seleccionar los contenidos disponibles en una variedad de fuentes internas y externas.

2. Describir las preferencias del usuario, en representación de los hábitos de consumo del usuario y la definición de otro tipo de información (por ejemplo, la demografía, modelos) para seleccionar un público específico.

3. Describir un contenido segmentado, esto es, una segmentación de metadatos que se utilice para editar el contenido de la grabación parciales y visualizaciones no lineales. En este caso, los metadatos se utilizan para navegar dentro de un contenido segmentado.

El estándar está estructurado en dos partes o fases. Una primera fase ya desarrollada que se encuentra formando parte de la ETSI como una especificación más, publicada como la especificación ETSI TS.102802-3, y una segunda fase que se encuentra en desarrollo. Esta segunda parte pretende afrontar el reto de que TV-Anytime sea aceptado por parte de los centros de radiodifusión de televisión y por los productores de contenidos, para crear contenidos enriquecidos con metadatos TVA.

Vamos a pasar a comentar lo más importante de la fase I. Nos centráremos en ella, pues es la única parte que ya ha sido estandarizada por la ETSI, y actualmente se esta usando en proyectos tan importantes como la iniciativa DVB-H (Digital Video Broadcasting Handheld). La segunda fase del estándar, que está todavía en desarrollo, aunque aporta una mejora significativa con respecto a la fase I, la dejamos a un posterior estudio mucho más detallado que el que aquí podríamos presentar, ya que excedería las pretensiones del proyecto.

7.3. METADATOS TV-ANYTIME: FASE ITV-Anytime es set abierto de metadatos para ser usados por la próxima generación de

los llamados PVRs (Private Video Recorders), también conocidos como PDRs (Personal Digital Recorders). Es un conjunto de herramientas que permitirán enriquecer las relaciones establecidas entre los productores de contenidos, los proveedores de servicios y los consumidores. Los dos objetivos principales que pretende cumplir TVA son:

● Permitir que los usuarios tengan un acceso personalizado a los contenidos que ofrecen los proveedores de contenidos, de acuerdo con los intereses específicos de cada uno de los usuarios.

● Añadir valor a los contenidos. Permitir a los usuarios acceder y utilizar dichos contenidos cuándo y dónde les plazca,sin tener que regirse por normas restrictivas en el uso y consumo de los contenidos.

La fase I de TV-Anytime ha desarrollado un conjunto de especificaciones que permiten la interoperabilidad, la búsqueda, selección, adquisición y manipulación de un contenido, de una forma de totalmente independiente de los medios utilizados en la entrega de dicho contenido. La radiodifusión de los contenidos es completamente uni-direccional, pero se complementa con servicios auxiliares bi-direccionales de información de basada en metadatos. Esto es posible

95

gracias a las herramientas que proporciona TVA, que abarcan:

● Las relaciones entre contenidos y usuarios mediante el uso de descripciones basadas en metadatos.

● La ubicación e identificación de un contenido.

● El acceso a servicios de metadatos y mecanismos de seguridad asociados.

Los metadatos TVA van a permitir describir los contenidos televisivos. Descripciones que se utilizarán para atraer a los usuarios al consumo dichos contenidos. Esta fase del estándar se puede dividir en dos partes principales.

● Parte A. Los schemas de Metadatos. El TV-Anytime Forum ha adoptado un XML basado en un lenguaje de definición de descripciones, (DDL) MPEG-7, para representar el formato que deben tener los metadatos. Este formato XML es en la actualidad ampliamente utilizado, ya que ofrece muchas ventajas como pueden ser la extensibilidad o la capacidad de separar los datos de la aplicación en las que se están utilizando. Por otra parte, especifica el formato de los metadatos que van a ser intercambiados entre, por ejemplo, el proveedor de contenidos y el usuario. Incluyendo el contenido, los servicios asociados y la descripción de los esquemas de los usuarios y de los sistemas de clasificación.

● Parte B. Aspectos del sistema. Esta parte contiene un formato binario basado en el MPEG-7 BiM ( ISO / IEC 15938-1 ) así como un modelo de fragmentación, encapsulación e indexación de contenidos y servicios auxiliares de metadatos.

Todos los documentos XML necesarios, para aplicar el estándar de metadatos TVA, se encuentran recogidos en la especificación SP003v13.

Como hemos dicho anteriormente, TV-Anytime puede ser adaptado a distintos ambientes de radiodifusión de contenidos, como son DVB o ARIB, ya que se encuentra completamente desacoplado de la capa de transporte. Por otro lado, la forma en la que los metadatos son almacenados, recuperados y utilizados por parte de los PVRs, no es algo que el estándar cubra en el pliego de condiciones que se ha desarrollado. La especificación SP006v10 define las distintas herramientas para acceder a los servicios auxiliares de metadatos a través de una red bi-direccional de comunicaciones..

7.3.1. PARTE A. ESQUEMAS DE METADATOS

7.3.1.1. MODELO DE DATOS DE TV-ANYTIME

Lo primero que vamos a mostrar es una figura donde podemos observar el flujo que siguen los metadatos y los contenidos a través las diversas etapas de creación y entrega al consumidor final.

96

Figura 39. Flujo de metadatos y contenidos .

La figura muestra como el procesado de metadatos y contenidos se encuentran claramente separados uno de otro, aunque se llevan a cabo de forma paralela. Por otro lado observamos cómo los metadatos, que describen el perfil del usuario y su historial, son generados durante la selección y presentación del proyecto. Vamos a pasar a explicar con un poco más de detenimiento cada uno de los elementos que aparecen la figura.

● Content Creation. El proceso de creación de contenidos ( televisivo o de radio) representa la producción de una parte de un contenido o de un programa. Para nosotros, un programa será un contenido que es adquirido por un PDR como un todo. Durante el proceso de producción se crea un programa y la información sobre dicho programa debe ser capturada mediante metadatos. Sin embargo, en esta etapa, los metadatos que contienen la información sobre le contenido o el programa no son legibles para un usuario final, por lo que deberán ser editados de alguna manera antes de que la descripción del programa pueda ser publicada.

● Content Publishing. Una vez se ha creado un contenido, éste se encuentra disponible para ser publicado por parte de un Content Publisher (publicador de contenidos). El proceso de publicación de un contenido viene a decirnos “dónde” un contenido podrá ser encontrado por un usuario.

● Metadata editing. El proceso de edición de metadatos toma la información a partir de la creación de contenidos y procesos, para hacer una edición de esta información, creando descripciones que puedan ser legibles por parte de un consumidor final. El resultado de este proceso es editar, tanto los metadatos que describen los programas, como los que

97

describen la ubicación de estos programas.

● Metadata aggregation. El proceso de agregación de metadatos es un proceso mediante el cual se añaden los metadatos de un número de creadores de contenidos independientes, con el fin de mejorar el sistema TV-Anytime. Este proceso puede conllevar que se modifiquen algunos de los metadatos inicialmente definidos en el estándar.

● Metadata publishing. Los metadatos del estándar deben ser publicados de forma que puedan ser utilizados tanto por los procesos de selección de contenidos. Los metadatos deben describir el contenido, para que el usuario pueda seleccionar el contenido que más le convenga. Además, describen los procesos de localización que sirvan para indicarnos dónde poder adquirir el contenido seleccionado.

● Content selection. La selección de un contenido se puede llevar a cabo, bien a través de la participación directa del consumidor, o bien por un agente software que lo haga en nombre del consumidor final. Con el fin de que un agente de software pueda funcionar correctamente, los metadatos que describen al consumidor y a sus preferencias tendrán que ser proporcionados a los procesos de selección de contenidos. Utilizando esta información dichos procesos ofrecerán al consumidor, para que los seleccione, un contenido determinado en función del tipo de usuario y del historial de consumo de contenidos que posee.

● Location resolution. El proceso de resolución de la localización de un contenido simplemente deberá permitirnos conocer dónde y cuándo podemos encontrar un contenido. Los detalles del proceso de descubrimiento de un contenido se encuentran disponibles en la especificación “TV-Anytime Content Referencing Specification”.

Una vez explicado el flujo de cómo los metadatos TV-Anytime se generan y se asocian a los contenidos, nos encontramos en disposición de mostrar cómo es el modelo de la estructura de los metadatos TVA. Para ello dos enfoques de modelado se utilizan en el estándar. En primer lugar, una simple metodología de modelado de datos que nos permite describir la estructura de metadatos de alto nivel, una forma independiente de cualquier representación particular. Esta sintaxis permite que las relaciones entre las entidades TV-Anytime se establezcan claramente (por ejemplo, uno-a-muchos), así como nos permite observar el poderoso concepto de herencia, donde determinadas entidades derivan de tipos genéricos. Esto se observa en la siguiente figura 40.

98

Figura 40. Modelo de relaciones básicas entre entidades TV-Anytime.

La otra forma de modelado de entidades que forman el estándar TV-Anytime, se basa en el uso de diagramas UML (Unified Modeling Language).

Como parte fundamental del modelo de dato de los metadatos TV-Anytime, vamos a explicar la relación existente entre los metadatos y el identificador CRID ( Content Referencing IDentifier). Como norma general, los CRIDs hacen referencia a una parte de un contenido determinado, aunque también sirve de vínculo entre diferentes contenidos con sus descripciones de metadatos. Estos metadatos se clasifican bien como metadatos de descripción de contenidos, bien como metadatos de descripción de instancias.

Como se muestra en la figura 41, los metadatos de descripción de contenidos llevan información sobre una parte del contenido que no cambia, independientemente de la forma en la que es publicado o emitido. Estos metadatos suelen llevar información como: el título, una descripción textual del contenido o el género del mismo. Por lo general, es el creador de un contenido quien asigna los metadatos de descripción del contenido antes de su publicación.

Por otro lado, los metadatos de descripción de instancias llevan información como: la ubicación del contenido, las reglas de uso (si es pay-per-view o en abierto, por ejemplo) o determinados parámetros de entrega (como el formato del video). Los metadatos de descripción de instancias son asignados por el proveedor de contenidos como parte de la publicación de los contenidos, de manera que durante la búsqueda y selección de un contenido, el usuario pueda hacer uso de los metadatos de descripción de contenidos en general y de los de descripción de instancias.

99

Figura 41. Metadatos referenciados mediante un CRID.

Una tercera categoría de metadatos son los llamados metadatos de consumo, que incluye el uso de metadatos sobre el historial (registro de datos), anotación de metadatos, y las preferencias de los usuarios. En la figura 41 se muestra los cuatro tipos de metadatos y la forma que el CRID de un elemento de contenido individual tiene para vincular a todos ellos juntos. Por supuesto, esto no es una lista completa de todos los metadatos TV-Anytime sólo se muestran unas pocas entidades representativas.

Continuamos con una representación de las relaciones existentes entre los principales tipos metadatos del estándar.

Figura 42. Relaciones existentes entre los principales tipos de metadatos TV-Anytime.

Los metadatos de programa describen información acerca de un sólo programa ( título, género, etc). Los programas se definen como una redacción coherente de trozos de contenidos que suelen ser adquiridos como un todo o conjunto. El programa se referencia a través de un

100

CRID, que nos permite localizarlo. El mismo programa se pueden encontrar en varios lugares distintos, ya que esto se encuentra previsto en el proceso de resolución de localización. Esta relación se indica a través de enlaces uno-a-muchos entre un “Program" y un “Program Location” , tal y como vemos en la figura anterior.

Por último, comentamos que los programas pueden ser agrupados en elementos del tipo "Programs Groups" o grupos de programas. Cada uno de estos elementos puede contener cualquier número de programas, y un programa puede ser miembro de cualquier número de grupos. Más aún, un grupo de programas puede pertenecer a otro grupo de programas. A su vez, los CRID, que identifican los programas, se van anidando conforme estos lo hacen para formar diferentes grupos de programas.

7.3.1.2. TIPOS DE METADATOS

7.3.1.2.1. METADATOS DE DESCRIPCIÓN DEL CONTENIDO

En esta sección pretendemos dar una idea de los metadatos utilizados para la descripción de un contenido independientemente de cómo esté instanciado el contenido. Para ello, el estándar tiene que tener en cuenta los siguientes conceptos a la hora de describir los contenidos:

● Que haya programas simples, una unidad completa de información.

● Que un mismo programa pueda tener diferentes versiones.

● Que un programa pueda estar dividido en diferentes partes que serán emitidas en días distintos.

● Que un programa tenga agregado otro programa.

● Que una serie de programas puedan ser ordenados o agrupados. Por ejemplo, una serie de televisión que se agrupa en capítulos, que a su vez se encuentran ordenados numéricamente.

● Que los programas puedan ser agrupados por conceptos, por ejemplo, agrupar todos los programas que sean shows especiales de Navidad.

● Que se puedan añadir atributos a los programas que sean utilizados a la hora de publicarlos.

El modelo de descripción de contenidos que usa el estándar TV-Anytime y en el cual se basa para la creación de los metadatos, deberá garantizar que dichos conceptos sean tenidos en cuenta a la hora de generar los metadatos. Este modelo se expone en la siguiente figura.

101

Figura 43. Modelo de descripción de contenidos en TV-Anytime.

En este modelo se distinguen claramente tres entidades.

1. Programa (Program). Un programa representa un conjunto de trozos de contenidos que por sí sólo puede agregar otros programas.

2. Grupo de Programas (Program Group). Como su propio nombre indica, es una entidad que agrupa a diferentes tipos de programas que tienen características en común. Por ejemplo, se definen entidades para series y shows. Una entidad Program Group puede tener en su interior otros grupos de programa.

3. Localización de Programa (Program Location). Esta entidad contiene información sobre dónde se encuentra un programa, o cuándo se publica. Se puede crear un calendario, de cuándo va a ser publicado un determinado programa, simplemente agrupando distintas entidades Program Location asociadas a dicho programa.

Una vez hemos distinguido las entidades que conforman el modelo de descripción de contenidos, pasamos a explicar las relaciones existentes entre ellas.

● Relación Programa a Localización de Programa. Para un programa dado, podemos tener varios localizadores de programa, aunque un localizador de programa sólo instancia un único programa.

● Relación Programa a Grupos de Programas. Un mismo programa puede estar incluido en varios grupos de programas, y un grupo de programas puede incluir varios programas.

● Relación Grupo de Programas a Grupo de Programas. Al igual que la relación anterior, ésta también es una relación muchos a muchos. Esto es, un grupo de programas determinado puede, tanto pertenecer a varios grupos de programas, como varios grupos de programas pueden estar incluidos en el.

● Relación Programa a Programa. Esta relación se basa en el hecho de que un mismo programa puede ser parte de más de un programa (como programa agregado), o puede tener más de un programa agregado.

Ahora que ya conocemos qué entidades intervienen en la descripción de un contenido y qué relaciones existen entre ellas, vamos a pasar a comentar un poco los metadatos de

102

descripción de contenidos. Los agrupamos en seis tipos.

● Metadatos de tipo básico. Son tipos, tanto complejos (están formados por otros metadatos), como simples que se utilizan en todo el estándar TV-Anytime.

● Metadatos de descripción. Son un conjunto de metadatos simples y complejos, que definen una serie de atributos descriptores de un contenido. Por ejemplo, su género, una sinopsis del contenido, el idioma, si tiene otros contenidos asociados, si ha ganado algún premio o está nominado, la fecha de producción etc. Mostramos a modo de ejemplo el metadato de descripción BasicContentDescriptionType.

Figura 44. Modelo de un metadato BasicContentDescriptionType.

● Metadatos de vídeo y audio. Estos son metadatos que describen atributos de vídeo y audio de un contenido. Se agrupan en un metadato complejo, conocido como AVAttributesType, que en su interior contiene elementos (metadatos) que describen el formato del audio o del vídeo, el tamaño, la tasa de bits y propiedades sobre el color de la imagen. En la siguiente figura se representa un modelo del metadato AVAttributesType.

Figura 45. Modelo de un metadato AVAttributesType.

103

● Metadatos de información de programas. Estos metadatos llevan información sobre un programa determinado. Se agrupan bajo el uso de un metadato principal, conocido como ProgramInformationType, metadato complejo en cuyo interior se encuentran los metadatos que describen un programa. Vamos a exponer el modelo de datos, tal y como estamos haciendo en los puntos anteriores.

Figura 46. Modelo de datos de los metadatos de Información de Programa.

● Metadatos de información de Grupo de programas. Éstos son metadatos que se utilizan para describir grupos de programas. Al igual que en casos anteriores, estos metadatos se encuentran agrupados formando parte de un elemento complejo conocido como GroupInformationType. En la figura podemos ver cuáles son los metadatos de información de grupo y cómo forman parte del GroupInformationType.

Figura 47. Modelo de datos de los metadatos de información de grupo de programas.

104

● Metadatos MediaReviewsDS. Son metadatos para incluir información adicional sobre un contenido, en concreto para incluir comentarios. Por ejemplo, estos metadatos nos permiten incluir las críticas existentes sobre una película.

Hay que tener en cuenta que los metadatos TV-Anytime serán procesados por una gran variedad de dispositivos, algunos de los cuales tendrán limitaciones técnicas muy importantes. Por ello, el estándar define qué metadatos son de uso obligado y cuáles, de entre todos los definidos, son de uso recomendado:

● Metadatos obligatorios. Encontramos solamente al metadato Title, que nos indicará el título del programa.

● Metadatos recomendados. En este caso encontramos los siguientes metadatos:

○ Synopsis.

○ Genre.

○ Language/CaptionLanguage/SignLanguage. Se recomienda que todos los ProgramInformation y GroupInformation tengan un conjunto significativo de elementos de estos tipos. El fin es poder definir el uso de las palabras, los subtítulos y las descripciónes de las propiedades del audio en el contenido.

● MemberOf. Es útil que lo utilicen los ProgramInformation y GroupInformation. Este metadato es una lista de los grupos (o programas asociados) a los que pertenece el programa.

● CreditsList. Lista de créditos de un programa.

7.3.1.2.2. METADATOS DE DESCRIPCIÓN DE INSTANCIAS

En la sección anterior nos ocupamos de la presentar los metadatos de descripción del contenido, asociando metadatos a diferentes trozos de los contenidos. La clave para vincular estos metadatos, a los contenidos, es el llamado CRID. En esta sección, se describen los metadatos de descripción de instancias. Para nosotros, las instancias vendrán a indicarnos cuándo y dónde un contenido va ser publicado para que un usuario pueda hacer uso de él. Puesto que un mismo contenido puede tener varias instancias, pensemos en una película que se emite por diferentes cadenas de televisión o por medios distintos (televisión e Internet de forma simultánea), éstas van a ser útiles para poder diferenciar contenidos que tienen un mismo CRID.

En primer lugar, vamos a explicar la relación existente entre contenidos e instancias de los contenidos. Para ello, explicamos el modelo de datos de la entidad Program Location, que ya

105

hemos comentado anteriormente.

Figura 48. Modelo de datos de una entidad Program Location.

Para poder comprender el modelo representado vamos a pasar explicar cada una de las entidades que lo componen.

● Program location. Esta entidad, comentada anteriormente, representa una ubicación genérica de un contenido, independientemente del medio por en el que será difundido o publicado (web, radio, etc.).

● Schedule Event. Nos indica dónde se va a publicar un contenido, a qué hora y qué duración tendrá.

● Service. Para hacernos una idea, un servicio viene a ser como una entidad por la que van los contenidos. Podemos pensar que es como un canal de televisión por donde se retransmite un flujo de material audiovisual, aunque no debemos confundirlo con el canal físico por el cual se transmite dicho material. Por lo tanto, el servicio no es equivalente al canal, porque un mismo servicio puede transmitirse por diferentes canales físicos,

Los metadatos de descripción de instanciación nos servirán básicamente para conocer:

1. Donde un usuario puede encontrar un contenido. Se basa en el metadato ProgramLocationType.

Figura 49. Modelo del metadato ProgramLocationType.

2. Sobre que servicio estará disponible un contenido, en qué fecha, a qué hora y qué

106

duración tendrá. Se basa en el uso del metadato ScheduleEventType.

Figura 50. Modelo del metadato ScheduleEventType.

3. Si el programa o contenido es, o no, bajo demanda, y cuándo comienza y deja de estar disponible. Se basa en el uso del metadato onDemandProgramtype.

107

Figura 51. Modelo del metadato OnDemandProgramtype.

4. Datos sobre el contenido que está siendo publicado: género, título,sinopsis, etc.

Figura 52. Descripción del metadato InstanceDescriptionType.

5. Información sobre los servicios que están disponibles:nombre, propietario del servicio, logo del servicio, etc.

108

Figura 53. Modelo del metadato ServiceInformationType.

7.3.1.2.3. METADATOS PARA DESCRIBIR AL CONSUMIDOR

Con el fin de conocer cuáles son los hábitos de cada consumidor, y así poder ofrecer contenidos adecuados a cada usuario de una forma automatizada, el estándar de metadatos TV-Anytime define un conjunto de metadatos. Estos metadatos serán básicamente de dos tipos:

● Metadatos UsageHistoryDS. Son metadatos pertenecientes al estándar ISO/IEC 15938-5 [2], en la sección 15.2 y que vienen a recopilar las acciones que realiza un usuario durante un determinado periodo de observación. Este historial podrá ser utilizado posteriormente para que mediante un análisis automático se pueda generar un listado con las preferencias de los usuarios. El uso del estándar de la ISO mencionado anteriormente, nos permite garantizar que la información sea adquirida de forma correcta y presentada de en el formato adecuado. Se producirá un correcto intercambio de información de los historiales de los usuarios, entre diferentes equipos y plataformas que usen TV-Anytime. El funcionamiento sería el siguiente: En una descripción siempre encontramos un UserIdentifier, este es un elemento que especifica el usuario o el grupo de usuarios que están consumiendo un contenido proporcionado. Para llevar un control del la historia de cada usuario, se crean unas listas denominadas UserActionHistory Descripción Plan, que guardan las acciones realizadas por el usuario durante un período de observación. Cada lista de acciones guarda las acciones, de un tipo específico, realizadas por el usuario (como el "juego" o "grabar"). Los tipos específicos de acciones que son seguidos (es decir, los valores permitidos para el elemento ActionType) se definen como miembros de una clasificación scheme/thesaurus1, lo que permite nuevos tipos de acciones que deben apoyarse en el futuro. Asociado a la acción de cada usuario tenemos el CRID, que nos indica en que momento tuvo lugar la acción y sobre que programa. Además, el CRID

109

contiene referencias y elementos opcionales que permiten enlaces a los recursos relacionados con el programa. Todo esto, nos permite llevar un control exhaustivo de los contenidos televisivos de cada uno de los usuarios. En las siguientes figuras podemos ver los modelos de datos de los distintos metadatos que conforman el UsageHistory.

Figura 54. Modelos de los metadatos utilizados en TV-Anytime para crear un historial de las acciones de un usuario.

110

● Metadatos UserPrefencesDS. Estos son metadatos que nos indican las preferencias de los usuarios a la hora de consumir material multimedia. Son descripciones relacionadas con la búsqueda, filtrado, selección y consumo de los contenidos deseados por cada usuario. Una correspondencia entre los metadatos de preferencias de los usuarios y los metadatos de descripción de los contenidos, nos permite realizar descripciones de los propios contenidos de una forma más personificadas y precisa. De esta forma, se facilita a los usuarios el acceso y consumo de los contenidos publicados. Los metadatos UserPreferencesDS, o metadatos de preferencias de usuario, están definidos en el estándar ISO /IEC 15938-5 [2], section 15 , de manera que podemos recurrir a este estándar para conocer mejor dichos metadatos. Sin embargo, al igual que hicimos con los metadatos de historial de usuario, vamos a mostrar los modelos de datos de algunos de los metadatos más importantes del esquema, en las figuras presentadas a continuación.

111

Figura 55. Metadatos de descripción de las preferencias de los usuarios.

7.3.1.2.4. METADATOS DE SEGMENTACIÓN

Nos referimos con segmentación a la capacidad de poder definir, acceder y manipular intervalos temporales dentro de un flujo A/V. Al asociar metadatos con diferentes segmentos, es posible reestructurar un flujo A/V, con el fin de generar alternativas de consumo y nuevos modos de navegación. Estas modalidades podrían incluir, por ejemplo, un resumen de lo más destacado de un contenido, o un conjunto de marcadores que apuntan a “titulares" dentro de una secuencia. Estos metadatos pueden ser proporcionados por los proveedores de servicios o los organismos de radiodifusión como un valor añadido, y/o generados por los propios espectadores.

En la siguiente figura se muestra las relaciones existentes entre las distintas entidades que forman parte de la segmentación de un programa.

Figura 56. Modelo de segmentación de un programa para un sistema TV-Anytime.

112

Aquí se presentan dos nuevas entidades que desconocíamos hasta ahora, pero que vamos a pasar a comentar a continuación.

● Segmento (Segment). Un segmento es un fragmento de un programa. Un segmento puede pertenecer a un único programa o puede ser un miembro del segmento de grupos múltiples.

● Grupo de segmentos (Segment Group). Denota a un conjunto de segmentos que se agrupan para un propósito en particular o debido a una propiedad compartida. Un segmento de grupo puede contener segmentos sueltos, o grupos de otros segmentos.

Una vez conocemos las entidades que participan en la segmentación de un programa, pasamos a comentar brevemente las relaciones existentes entre ellas.

● Programa-a-Segmento. Un segmento es parte de un programa, identificado por un CRID, mientras que un programa puede contener muchos segmentos.

● Segmento-a-Grupo de Segmentos. Un segmento puede pertenecer a un grupo de segmentos o a ninguno, mientras que un grupo de segmentos puede contener múltiples segmentos de programas distintos.

● Grupo de Segmento-a-Grupo de Segmentos. Un grupo de segmentos puede ser miembro de otro grupo de segmentos. Los grupos de segmentos pueden contener o bien segmentos o bien otros grupos de segmentos, aunque no ambos a la vez.

Para describir los segmentos simples se utilizan una serie de metadatos que describen sus propiedades. Metadatos como el BasicSegmentionType o el SegmentationInformation, nos permiten conocer un título del segmento, una sinopsis, si tiene material relacionado, el programa al que pertenece o una descripción del contenido que guarda en su interior. Por otro lado, encontramos también metadatos que nos describen grupos de segmentos, caso del SegmentGroupInformationType. A modo de ejemplo mostraremos algunos de los modelos de los metadatos de segmentación, en las siguientes figuras:

113

Figura 57. Modelos de metadatos de segmentación.

7.3.2. PARTE B. ASPECTOS DEL SISTEMA

7.3.2.1. ASPECTOS DEL SISTEMA EN UN AMBIENTE UNIDIRECCIONAL

La parte B del estándar define diferentes mecanismos que habilitan y optimizan la entrega de metadatos TV-Anytime. Esta parte no trata directamente sobre los metadatos TV-Anytime, sino mas bien sobre còmo estos se entregan a los terminales TVA. No obstante, haremos una pequeña revisión a esta parte del estándar, con el fin de poder comprender mucho mejor el funcionamiento y uso del mismo. En la siguiente figura mostramos un modelo de como se envían los metadatos TVA en un enlace unidireccional.

Figura 58. Proceso de descripción de metadatos para la entrega sobre un enlace unidireccional.

Los principales requerimientos técnicos, para este tipo de enlaces, son los siguientes:

1. Eficiencia del ancho de banda.

2. Capacidad para poder entregar los metadatos de forma asíncrona usando un carrusel.

3. Modularización de la información con el objetivo de poder ofrecer actualizaciones parciales y selectivas, y permitir una cierta prioridad en la forma de transmitir cíclicamente la información.

4. Mejora de la navegabilidad dentro de la información a fin de proporcionar, cuando sea

114

necesario, una manera eficaz para poder recuperar las partes más importantes de la información.

El principal objetivo es poder transmitir los metadatos de descripción TV-Anytime descritos en la parte A del estándar. Para ello, se crea un documento XML, que siguiendo el esquema descrito también en la parte A, contenga todos los metadatos necesarios. Este documento deberá ser entregado a un terminal TV-Anytime, para su posterior procesado.

Para poder cumplir estos objetivos, los equipos TVA se basan en procesos de transmisión, recepción y procesado de fragmentos TVA. Para poder entregar los metadatos, estos se llevan a cabo tres procesos básicos que debemos tener en cuenta:

● Fragmentación. Como hemos comentado ya en puntos anteriores, la fragmentación es un mecanismo mediante el cual las descripciones de metadatos TV-Anytime se descomponen en unidades de datos denominadas fragmentos TVA. Los fragmentos TVA son unidades atómicas de metadatos, transmitidas libremente por los terminales TVA. Al ser independientes unos fragmentos de otros, se pueden actualizar, adquirir y procesar de forma distinta, dependiendo del fragmento que sea. La decodificación de un fragmento, por parte del terminal, y su posterior adición a una descripción parcial de un contenido, deberá ir acompañada de un schema de validación propio de TV-Anytime. De esta forma, se podrá asegurar que la descripción parcial se corresponde a un documento TV-Anytime que se podrá reconstruir en el receptor TVA.

En la siguiente figura podemos ver un esquema de como sería una fragmentación de una descripción de metadatos TVA.

Figura 59. Modelo de fragmentación de una descripción con metadatos TVA.

El estándar TV-Anytime define fragmentos tales como los comentados a continuación:

● Un fragmento que contiene la descripción de un programa, de un contenido, o de un determinado grupo de contenidos.

115

● Un fragmento que contiene descripción de una instancia de un determinado contenido, bien sea bajo demanda o de difusión.

● Un fragmento que contiene información sobre un servicio bajo demanda o de difusión.

● Un fragmento que describa cuándo, dónde y durante qué periodo se va a difundir un contenido sobre un determinado servicio.

● Un fragmento que contenga un SegmentInformation o SegmentInformationGroup, de un contenido determinado.

Como hemos comentado anteriormente, cada uno de estos fragmentos puede ser adquiridos y procesados de forma independiente. En un posible escenario los fragmentos de descripciones con metadatos se enviarían acompañando a los propios contenidos a los que describen, de manera que se reciban los contenidos con una información extra.

Para tener una mayor eficiencia de ancho de banda, para el transporte y la entrega de los fragmentos de metadatos TV-Anytime, estos deben ser codificados, por ejemplo, en código binario. Con este fin, el estándar recomienda el uso de MPEG-7 BiM (MPEG-7 es un estándar amplio, que no sólo incluye una parte sobre metadatos) en asociación con la biblioteca de compresión de datos textuales Zlib. BiM (Binary MPEG format for XML). Es un estándar internacional que define un formato binario genérico para la codificación de documentos XML. Con el uso de este estándar lo que se pretende es realizar una tokenización de cada fragmento respecto al diagrama de estados producido por el esquema de TV-Anytime. Por lo tanto, se pretende desmenuzar cada fragmento en pequeños tokens o elementos que poder codificar usando cada uno de ellos de forma independiente usando BiM.

● Encapsulación. La encapsulación, es el proceso mediante el cual se habilita el agrupamiento de fragmentos codificados en contenedores preparados para ser transmitidos. Estos contenedores se asocian a más información sobre los fragmentos, como un identificador único o un número de versión, que permita la gestión y el seguimiento de los cambios que se producen. En la siguiente figura vemos un mecanismo de encapsulación de metadatos de descripción TVA.

116

Figura 60. Modelo de encapsulación de metadatos de descripción TVA.

● Indexado. Es un mecanismo opcional para la entrega de metadatos de descripción TV-Anytime a receptores con un capacidad limitada de procesado y almacenamiento. Proporciona un mecanismo para localizar la información dentro de un flujo de fragmentos, formando una descripción de metadatos TVA. La indexación, de las estructuras que acompañan a un flujo de fragmentos, nos permite tener un acceso directo a cada uno de los fragmentos listados en un nodo particular, donde se detalla las coincidencias de los fragmentos para que puedan ser localizados en la capa de entrega. Veamos un ejemplo gráfico dónde se muestre lo que hemos comentado.

117

Figura 61. Modelo de uso de la indexación de contenedores TVA.

TV-Anytime no define de una manera exacta como se debe llevar a cabo la indexación de los contenedores, ni las estructuras que deben utilizarse ya que TVA pretende seguir siendo transparente en la capa de transporte. Esto se deja a los organismos de normalización que están adoptando la solución TV-Anytime (por ejemplo, ARIB, ATSC y DVB).

7.3.2.2. ASPECTOS DEL SISTEMA EN REDES BIDIRECCIONALES

Quedan definidos por métodos y protocolos especificados en el estándar TVA SP006v10, que permite el uso de un rico conjunto de metadatos auxiliares para el el intercambio entre los clientes TV-Anytime y los servidores de metadatos, a través de una red bi-direccional complementada por servicios uni-direccionales. Estos protocolos también permiten, a los proveedores de servicios, el acceso de perfiles anónimos de los consumidores para conocer sus preferencias.

Para descubrir los servicios de metadatos, o más exactamente, para conocer donde se encuentra los servidores donde se pueden recuperar los metadatos TV-Anytime, se utilizan mecanismos que bien pueden ser definidos por el propio TVA Forum. Dichos mecanismos proveen de los URLs adecuados, mediante un flujo uni-direccional, u otro tipo de mecanismos genéricos, para el descubrimiento de servicios web, como por ejemplo, el WS-Inspection creado por el consorcio W3C.

Uno de los mecanismos, definidos en la especificación SP006v10, describe cómo inicializar a un cliente para poder solicitar metadatos y permitir que realizar un envío de confirmación al servidor, todo ello mediante un servicio web basado en IP. Se trata de un servicio web que realiza dos operaciones básicas:

118

● get-Data. Operación mediante la cual un cliente hace una petición al servidor para que este le envíe una serie de datos TVA, como por ejemplo, determinados grupos de programas. Esta operación podría, en principio, soportar peticiones complejas, utilizando expresiones XPath (XML Path Language es un lenguaje que permite construir expresiones que recorren y procesan un documento XML , sigue una idea similar a la expresiones regulares para poder seleccionar partes concretas de un texto).

● submit_Data. Es una operación que permite simplificar y limitar los datos que pueden ser enviados al servidor, definiendo un conjunto de perfiles de datos que se rellenan mediante la entrada manual de los datos o mediante agentes inteligentes que se basan en el uso de servicios y contenidos. Estos servicio se encuentran también definidos en la especificación SP006v10.

Como se puede observar, para continuar ampliando los conocimientos sobre la parte B del estándar TVA, lo ideal será recurrir a la especificación citada anteriormente (SP006v10). Nosotros abandonamos aquí el estándar de metadatos TVA, y con ello, cerramos el capítulo sobre algunos de los estándares de metadatos más extendidos hoy en día, en el mundo de las comunicaciones digitales.

Como se puede entender, no sólo nos han quedado estándares por comentar, sino que de los que hemos hablado, no hemos hecho más que una breve introducción en cada uno de ellos. Dicha introducción buscaba ponernos en contacto con algunos de los estándares de metadatos utilizados hoy en día, con el ánimo de que podamos familiarizarnos un poco más con ellos.

Con esto concluimos el capítulo, dando paso a un siguiente capítulo donde se pretenderá demostrar como los metadatos se utilizar hoy en día en proyectos reales, que son el futuro de las telecomunicaciones.

119

CAPÍTULO 3. USO DE METADATOS EN PROYECTOS REALES DE I+D+i

1. METADATOS Y LA WEB SEMÁNTICA

1.1. INTRODUCCIÓNLa Web semántica es un proyecto a corto, medio y largo plazo del organismo de

regulación más importante del mundo en relación a Internet: el World Wide Web Consortium, conocido como W3C . El proyecto de la Web semántica incluye transformaciones que ya están afectando a los ámbitos de la creación, edición y publicación de páginas y sitios Web y que seguirán teniendo una importancia creciente en el futuro. En este capítulo, se expondrán los conceptos e ideas más importantes relacionadas con la Web semántica.

El W3C (www.w3.org) es el organismo que regula aspectos esenciales de la Web, tales como, el lenguaje (X)HTML con el cual se crean las páginas y los sitios web. Puede decirse que es, con mucha diferencia, el organismo de normalización más importante de Internet. Siendo su director el propio fundador de la Web, Tim Berners-Lee, sus recomendaciones, que tienen carácter normalizador, poseen un gran prestigio y una enorme influencia. La Web semántica es el proyecto del W3C para transformar la Web en la Web de las próximas décadas. Ante todo veamos la definición oficial de la Web semántica según el W3C:

“La Web semántica proporciona un marco común que permite que los datos sean compartidos y reutilizados a través de aplicaciones, empresas y fronteras comunitarias. Es un esfuerzo colaborativo liderado por el W3C con la participación de un gran número de investigadores y socios industriales. Está basado en Resource Description Framework (RDF) e integra una variedad de aplicaciones utilizando XML para la sintaxis y URI para las denominaciones (www.w3.org/2001/sw/)”.

Dos breves apuntes sobre la definición anterior. En primer lugar, es una definición un tanto críptica, tal como acostumbran a ser las definiciones del W3C. Lo segundo a comentar es que debemos señalar que la Web semántica no es aún una realidad. De acuerdo con las estimaciones del W3C, el despliegue total de la Web semántica puede prolongarse más allá del año 2010.

Sin embargo, la Web semántica ya está entre nosotros de diversas formas. En primer lugar bajo la forma de una auténtica idea-fuerza, en el sentido de que es una idea que ya ha sido capaz de movilizar energías (e ilusiones) y que, sin duda no dejará de arrojar resultados positivos durante los próximos años. En segundo lugar, aportando nuevos estándares que ya son de uso habitual (como el lenguaje XML) e influenciando en el desarrollo de la nueva generación de navegadores y editores de páginas web.

En todo caso, volviendo a su definición, en el proyecto de la Web semántica conviven dos grandes visiones, o dos grandes ideas-fuerza, cuya confluencia a veces dificulta su

120

interpretación. Por este motivo, proponemos dos definiciones separadas (que se pueden complementar) de la Web semántica:

● Definición 1. La visión de la Inteligencia Artificial: “La Web semántica es un conjunto de iniciativas destinadas a promover una futura Web cuyas páginas estén organizadas, estructuradas y codificadas de tal manera que los ordenadores sean capaces de efectuar inferencias y razonar a partir de sus contenidos.”

● Definición 2. La visión del procesamiento robusto: “La Web semántica es un conjunto de iniciativas destinadas a convertir la World Wide Web en una gran base de datos capaz de soportar un procesamiento sistemático y consistente de la información.”

Lo que intenta poner en evidencia la primera definición es la visión, o la idea presente, en el proyecto de la Web semántica que proviene de la Inteligencia Artificial (IA). Es útil recordar que, históricamente, en el campo de la IA se han manejado dos hipótesis: las denominadas hipótesis fuerte y débil. La hipótesis débil sostiene que es posible conseguir ordenadores con inteligencia simulada y con diversos grados de éxito dependiendo del contexto. La hipótesis fuerte afirma que los ordenadores pueden alcanzar inteligencia real e indiferenciable de la humana (Penrose, 1991; Copeland, 1996).

Es evidente que los ordenadores actuales no son capaces de razonar ni de realizar inferencias en un modo similar al de los seres humanos. Tras varias décadas de investigación en IA, no hay ni un sólo atisbo sobre qué clase de cambio de paradigma en la computación podría conducir en el futuro, aunque sólo fuera hipotéticamente, a dotar de inteligencia real a las máquinas. Por tanto, debemos dejar claro que la clase de “razonamientos” que puede esperarse que sean capaces de realizar los ordenadores en el futuro sería, en el mejor de los casos, una simulación del razonamiento como la que postula la versión de la hipótesis débil de la IA.

Veamos ahora la definición 2 vinculada a la visión del procesamiento robusto. Lo que separa a un conjunto de documentos con información no estructurada, y por tanto difícil de procesar y de explotar su contenido, respecto de un conjunto de registros de una base de datos es la suma de tratamiento sistemático + metadatos propios de estos últimos (y ausente en los primeros). Recordemos que la creación de una típica base de datos documental consiste en definir un grupo de campos, lo que equivaldría en nuestro caso a definir un conjunto de etiquetas como <autor>, <título>, etc., para marcar sistemáticamente en cada documento de la base de datos la información que en el documento original aparece sin ninguna identificación explícita. El segundo paso consistirá en vincular cada documento con metadatos mediante etiquetas del estilo <clasificación>, <tipo de documento>, <descriptores>, <fecha de creación>, etc. (Abadal, Codina, 2005).

Una vez tenemos todo lo anterior, hemos pasado de información desestructurada a información sistematizada, en la que cada línea de texto, cada párrafo o cada grupo de párrafos forman parte de un campo y están vinculados a un conjunto de metadatos. A partir de aquí, será sencillo conseguir que la base de datos simule una cierta inteligencia, de la que carecen en estos momentos los motores de búsqueda, ya que será capaz de responder a preguntas que actualmente no puede responder un motor de búsqueda. Por ejemplo, en la actualidad no existe forma de pedir a un motor de búsqueda que busque documentos donde la palabra Eco se refiera

121

al nombre de un autor y no a un fenómeno acústico. En cambio, en una base de datos documental es una operación tan trivial que nos pasa absolutamente desapercibida. Es a esta clase de procesamiento sistemático (predecible) y consistente a la que nos queremos referir con la expresión de procesamiento robusto.

Ahora bien, dada esta dicotomía, ¿hay algún elemento que nos permita unificar o al menos articular las dos visiones? La respuesta, al menos bajo mi opinión, es que sí. Si observamos los elementos de infraestructura en los que confía la visión de la IA, vemos que son, en parte, los mismos que se requieren para crear una base de datos, es decir, los mismos de la visión del procesamiento robusto.

En primer lugar, la visión de la IA requiere páginas codificadas de forma consistente, es decir, sin ambigüedad ni contradicciones; pero esto es exactamente lo que proporciona la estructurada basada en campos, propia de una base de datos. En segundo lugar, la IA requiere una capa de metadatos que contenga declaraciones sobre las propiedades de los sitios web. Sucede que la asociación sistemática de metadatos, a cada documento, es lo que corresponde a la práctica de la indización, catalogación, categorización, etc., tan característica de las bases de datos en general, pero muy en particular, de las bases de datos documentales. Lo que separa a ambas visiones es lo siguiente: la primera idea es claramente visionaria, para bien y para mal, al confiar en obtener como resultado ordenadores capaces de razonar. Para bien, porque, sin duda, a veces se requieren de ideas visionarias para abrir nuevos caminos o para salir de una situación estancada. Para mal, porque a veces las ideas visionarias, al ignorar los hechos más elementales malgastan grandes esfuerzos.

La segunda visión, la del procesamiento robusto, está mucho más pegada al terreno real, a lo que, hoy por hoy, es factible. Es solvente, porque se basa en elementos bien probados en el procesamiento de la información, y esa es su gran virtud. Su problema es que carece de la capacidad de fascinación de la primera. Es posible que, si el proyecto de la Web semántica se hubiera limitado a esta segunda visión, nunca hubiera trascendido de las páginas de las revistas especializadas.

El proyecto de la Web semántica se enfrenta a nuevos retos cualquiera que sea la visión adoptada. Nunca se había intentado aplicar la IA a un entorno abierto y descentralizada como es la Web. Tradicionalmente, la IA, se había aplicado a dominios del conocimiento y conjuntos de datos bien diferenciados. El modelo clásico son los sistemas expertos, que se limitan a un dominio y a un conjunto de datos restringido. Un ejemplo es, Dendral, un sistema experto para el análisis químico, o Mycin, un sistema experto que ayuda a diagnosticar enfermedades infecciosas de la sangre.

Por otro lado, la visión del procesamiento robusto también se enfrenta a retos. Las bases de datos funcionan bien porque, al igual que los sistemas expertos (aunque en un sentido distinto) se limitan a una colección de documentos bien delimitada, aunque sea enorme (pensemos por ejemplo en los millones de registros de Medline o Eric en los cientos de millones de documentos en texto completo de Lexis-Nexis). Es cierto que la Web semántica sería equiparable a una base de datos distribuida como las que ya existen actualmente. El problema es que no existen precedentes, ni mucho menos, de una base de datos distribuida con las dimensiones de la Web, y aún menos, una base de datos distribuida que no cuenta con ninguna

122

clase de mecanismo o procedimiento de coordinación entre los componentes de esa base.

En todo caso, para entender mejor lo que significa este proyecto sin duda es útil considerar cómo es la Web actual, a la cual podemos denominar, por oposición a la Web semántica, la Web sintáctica.

1.2. LA WEB SINTÁCTICALas páginas HTML actuales disponen de etiquetas tales como h1, h2, etc., para

marcar la importancia relativa de cada sección de la página: en concreto, la etiqueta h1 está destinada a marcar el título principal de la página, mientras que h2, h3, etc., representan a su vez los títulos de las secciones de segundo, de tercer nivel, etc. Otro ejemplo, son las etiquetas para otorgar énfasis al texto, como cité para señalar la transcripción literal de un texto.

HTML, por tanto, aporta algunas etiquetas con valor estructural o funcional, mientras que otras etiquetas, como <b> o <i>, sirven en cambio únicamente para señalar elementos gráficos. Para ser más exactos, indican al navegador que el texto que aparece entre los elementos <b> y <b> deben ser mostrados en negrita, mientras que el texto que aparece entre <i> e </i> debe ser mostrado en cursiva. El problema con esta codificación es doble: no solamente carece de cualquier interpretación semántica, sino que, además, sus etiquetas son susceptibles de uso inadecuado: algunas páginas web contienen los elementos h1, h2, etc., intercalados de forma contraria al nivel estructural que representan, por ejemplo, puede aparecer un elemento h1 después de un elemento h2 para conseguir el efecto tipográfico asociado por el navegador con la etiqueta (negrita y un cuerpo más grande). También, puede suceder exactamente lo contrario, es decir, que el título principal y los títulos de las secciones carezcan de la etiqueta correspondiente y, en su lugar, el autor de la página haya intentado marcar su importancia mediante atributos de formato (como negrita o cursiva y distintos cuerpo de letra) en lugar de estructurales (como h1, h2,...).

El resultado es una Web donde la codificación de las páginas, además de poseer un nulo valor semántico (una de las pocas excepciones es la etiqueta <title> de la sección de cabecera de la página), se puede utilizar de forma contraria a su función, por lo que ni tan solo son fiables los indicios que podrían proporcionar las etiquetas funcionales. En tales condiciones, la interpretación semántica certera de la página es imposible por parte de analizadores automáticos. Como resultado, las páginas web tienen semántica únicamente para los seres humanos. En efecto, tal como se codifican las páginas web actuales, principalmente mediante el lenguaje HMTL, tienen muy poco sentido para las máquinas. Si vemos el código fuente de una página web actual, encontramos, por ejemplo, un trozo de código como el siguiente:

Figura 62. Código HTML.

Cuando el ordenador lo interprete a través del programa navegador, aparecerá un texto en negrita y cursiva, como éste:

123

Figura 63. Interpretación de un código HTML.

1.3. BÚSQUEDA BASADA EN CADENAS DE CARACTERESCon lo anterior se acaba una buena parte de lo que es capaz de hacer un ordenador

con las páginas HTML. Pero, como saben bien informáticos y documentalistas, otra cosa que pueden hacer los ordenadores es construir índices con las palabras que aparecen en las páginas web. Después cuando alguien envía una pregunta a un motor de búsqueda, lo que hace este último es comparar las palabras de la pregunta con las palabras de su índice. Por ejemplo, supongamos que el responsable de un programa de gobierno sobre el problema de la brecha digital decide indagar en Internet para ver si encuentra estudios o informes sobre la brecha digital.

Supongamos que accede a Google y entra la siguiente pregunta: "brecha digital". Lo que hará Google es comparar las palabras de su pregunta, con las palabras de su índice. Si encuentra un documento que tenga la "brecha digital", lo devolverá como respuesta. Esto es casi todo lo que pueden hacer los ordenadores que tenga que ver con procesamiento de información en páginas web.

Con estas limitaciones, aunque la búsqueda en Internet está repleta de satisfacciones (no es difícil encontrar cosas valiosas en la Web con ayuda de los motores de búsqueda), también provoca muchas frustraciones. Si alguien busca por "caballos", no encontrará nada que trate sobre "yeguas" o sobre “potros”. Si alguien busca sobre “cómo evitar la guerra”, no encontrará un documento sobre cómo conseguir la paz, por la simple razón de que las cadenas de caracteres no coinciden. En una búsqueda basada en la palabra clave “depresión” el ordenador no tiene forma de saber si buscamos documentos sobre geografía, sobre psicología o sobre el clima.

Quizás, lo peor es la imposibilidad de precisar géneros documentales (artículos de revista vs. entradas de diccionario, por ejemplo) o puntos de vista en una búsqueda. Por ejemplo, una búsqueda sobre “Pentium 4” arrojará una buena cantidad de páginas de comercio electrónico. Si eso es lo que quiere el usuario, es decir, encontrar tiendas de informática en Internet, no hay ningún problema. Pero, si lo que quiere es encontrar documentación técnica sobre microprocesadores de la marca Pentium 4 así como análisis y comparaciones con otras marcas, por ejemplo, con AMD, probablemente deba dar la búsqueda por imposible dada la supremacía de las páginas web dedicadas al comercio electrónico en las listas de resultados de los motores de búsqueda.

Tampoco es posible precisar lo que podemos llamar la granularidad de la respuesta. Si buscamos información sobre un país, por ejemplo, Botswana, no es posible indicar si queremos una síntesis breve de sus condiciones de vida sociales y de su forma de gobierno o un estudio detallado de economía con cientos de estadísticas sobre todas las dimensiones económicas y políticas de Botswana (a través de las cuales, sin duda, si pudiéramos dedicar el número de horas suficientes tal vez podamos deducir lo anterior).

No existe la posibilidad de poder expresar puntos de vista. Por ejemplo, supongamos

124

la necesidad de información que denominaremos N1, y que consistente en que necesitamos encontrar información sobre aplicaciones de la Web semántica a la documentación. Hasta ahora, lo único que puedo hacer para expresar una necesidad de información como N1 es construir una ecuación booleana, que denominaremos E1, como esta: [Web semántica AND documentación]. El problema es que la ecuación E1 serviría a la vez para todas estas necesidades de información distintas, y de las cuales posiblemente solamente una de ellas es la requerida por el usuario:

1. N1: Web semántica aplicada a la documentación. Por ejemplo, RDF para representar lenguajes documentales.

2. N2: Documentación “de” la Web semántica. Por ejemplo, el tutorial de un programa para editar archivos en formato XML.

3. N3: Documentación “sobre” la Web semántica. Por ejemplo, la página oficial del World Wide Web Consortium sobre la Web semántica

4. N4: Documentación aplicada a la Web semántica. Por ejemplo, bibliotecas, archivos o centros de documentación dedicados a la Web semántica.

Si tomamos como ejemplo a los lectores interesados en este capítulo, resulta que solamente los documentos que responden a la necesidad de información N1 resultarán de utilidad, basándose en el uso de metadatos estandarizados con el protocolo RDF. Un motor de búsqueda como Google, no obstante, devolverá como respuesta de forma indiscriminada documentos correspondientes a las necesidades de información N1, N2, N3 y N4 por la simple razón de que no existe ningún procedimiento para especificar los objetivos de la búsqueda, ni el género o la clase de documentos solicitados ni tampoco el punto de vista concreto que necesita el usuario.

1.4. LA WEB SEMÁNTICALa Web semántica puede ser la respuesta a los problemas anteriores, aunque el

proyecto intenta ir mucho más allá. Comencemos por señalar que, en la Web semántica, en lugar de búsquedas por comparación de cadenas de caracteres, se espera que los sistemas de información sean capaces de buscar por conceptos, para ello se apoya en el uso de los metadatos, capaces de definir, clasificar e identificar dichos conceptos.

Si buscamos por caracteres, las palabras de la pregunta y las palabras del documento (o del índice de documentos) deben coincidir letra a letra. En cambio, si buscamos por conceptos, lo de menos es la palabra. Lo importante es el concepto. Esto suena a inteligencia artificial. Por tanto, aunque existe una cierta resistencia a llamarlo así, con la Web semántica se está buscando el mismo objetivo que la IA, a saber, que los ordenadores entiendan que un documento sobre "equinos" puede ser muy relevante para una necesidad de información sobre "caballos", y que conceptualmente las preguntas "¿es posible parar la guerra?" y "¿es posible alcanzar la paz?" son en realidad la misma pregunta.

Por tanto, entre los objetivos de la Web semántica se encuentra la posibilidad de que sea posible sostener una interacción entre un usuario y un agente de software mediante el cual el primero pueda ir expresando y perfilando sin ambigüedad puntos como los siguientes: objetivos de la búsqueda, géneros documentales pertinentes, punto de vista, granularidad esperada en la

125

respuesta, etc. A partir de aquí, se espera que el agente de software sea capaz de elaborar una estrategia de búsqueda según su propia iniciativa (la del agente de software) que involucre el uso de lenguajes documentales, metadatos y ontologías para responder con eficacia y rapidez al usuario. Se espera igualmente que los ordenadores puedan desarrollar tareas de gestión que requieran interpretar información y tomar decisiones adaptándolas al contexto. El mejor ejemplo de este tipo de tareas lo proporcionó el propio Tim Berners-Lee junto con dos de sus colaboradores en el año 2001 (Berners-Lee, Hendler y Lassila, 2001). En este artículo, los autores mencionados explicaban el caso como de unos usuarios del futuro (para cuando se escribió ese artículo se estaba pensando en unos 5 años vista, por la tanto ya debería ser posible) podrían encargar a un agente de software el establecimiento de citas para sesiones de fisioterapia. Vamos a reproducir lo que señalaba el citado artículo, con la idea de que de hacernos una idea más precisa de lo que puede ofrecernos una Web semántica, si esta llega algún día a implementarse:

“Lucía, desde la consulta del médico, dio instrucciones a su agente de la Red semántica (Web semántica, esta no es más que una traducción propia de la publicación del articulo en la revista Investigación y Ciencia, en Junio de 2001) mediante su navegador portátil. Al cabo de unos instantes, el agente había obtenido del agente del médico la información necesaria sobre el tratamiento prescrito, había consultado varias listas de profesionales, y verificado cuáles pertenecían al seguro médico en un radio de 30 kilómetros del domicilio de ésta, y habían recibido valoración de excelente o muy bueno por servicios de evaluación de calidad dignos de confianza. El agente empezó entonces a buscar concordancias entre las horas de cita previa de que disponían estos profesionales (proporcionados por los agentes de cada uno de ellos desde sus sitios en la Red) y los escasos huecos con que contaban los atareados Germán y Lucía.(Berners-Lee, Hendler y Lassila, 2001).”

El término agente en todo el párrafo citado (no solamente en la primera línea) se refiere a un programa informático con autonomía para realizar acciones e incluso adoptar decisiones (aunque sean luego revisadas por el usuario) inteligente. Respecto a los términos en negrita, señalan los autores: “Las palabras clave resaltadas denotan términos cuya semántica […] “ le fue definida al agente a través de la Red semántica”. Es decir, de acuerdo con los autores, términos como “tratamiento prescrito”, “profesionales”, “domicilio”, etc., serán entendidos, es decir, tendrán valor semántico, para el agente de software.

Presentada en estos términos, no es descabellado concluir que la Web semántica incluye, como ya hemos destacado antes, un objetivo al que la informática ha denominado hasta ahora Inteligencia Artificial. Al menos un tipo de IA que con ciertas limitaciones la hacen más factible y nos permite comenzar un camino en el que las computadoras puedan de algún modo “razonar” ciertas respuestas. Todo esto pretende conseguir, como veremos un poco más adelante, usando (entre otras cosas) a los propios metadatos y el enorme potencial que nos ofrecen los estándares que están apareciendo de los mismos.

1.5. INFRACTRUCTURA DE LA WEB SEMÁNTICA Los medios con los cuales se persiguen los objetivos de la Web semántica que hemos

presentado anteriormente son, a grandes rasgos, los siguientes: en primer lugar, una codificación

126

de páginas en la cual las etiquetas tengan, precisamente, carga semántica. Este apartado corresponde al estándar denominado XML (eXtensible Markup Language). En segundo lugar, aportando descripciones (basándonos en el uso de los metadatos) de las páginas y sitios web con un formato que sea compatible con la estructura general de la Web y con diversas categorías de páginas e interoperable entre distintos sistemas informáticos. De esto se ocupa la norma o estándar RDF (Resource Description Framework). En tercer lugar, mediante un sistema de ontologías que permitan especificar conceptos de los diversos dominios del conocimiento mediante el uso de un lenguaje fuertemente basado en lógica simbólica y susceptible, por tanto, de ser eventualmente interpretado por un ordenador. De este aspecto se ocupa el denominado OWL (Web Ontology Language).

No obstante, el proyecto de la Web semántica está formado por una auténtica sopa de letras, dada la diversidad de normas, protocolos, lenguajes y especificaciones involucradas. De hecho, existe un famoso diagrama creado por Tim Berners-Lee, que posee una gran capacidad expresiva, y que pretende abarcar la totalidad del proyecto mediante una metáfora de capas que comprende 7 niveles y que reproducimos a continuación:

Figura 64. La Web semántica como modelo de capas.(Tim Berners-Lee,2001).

En la siguiente tabla presentamos con un poco de más detalle el significado de cada una de las capas que aparecen en la figura mostrada anteriormente.

127

Tabla 8. Niveles de la Web semántica.(Tim Berners-Lee 2001).

128

Como se ha comentado anteriormente solamente los tres primero niveles del modelo se están desarrollando, aunque no lo están su totalidad. Respecto al resto de niveles, es cierto que se ha generado una gran cantidad de documentación tanto técnica como científica, e incluso filosófica, pero no se ha desarrollado nada aún que pueda ser reseñable, de manera que, a todos los efectos, son capas que se encuentran aun en un estado embrionario aun por desarrollar.

Por lo tanto, en estos momentos, y al menos en un futuro cercano, XML, RDF y OWL (y por este mismo orden) serán con mucha diferencia los pilares más importantes del proyecto, razón por la cual, a partir de ahora, nos centraremos en ellos. Tanto el estándar RDF como el estándar OWL son estándares de metadatos que hemos estudiado en puntos anteriores, aquí intentaremos mostrar como dichas normas de metadatos son aplicables en el proyecto de la Web semántica, formando parte de los pilares básicos de dicho proyecto.

1.5.1. XML Y LA WEB SEMÁNTICA XML es sin ninguna duda el elemento de la Web semántica que mayor repercusión

tiene ya (y que sin duda continuará teniendo en el futuro) en la Biblioteconomía-Documentación. XML es un estándar (una recomendación en palabras del W3C) que, junto con su norma asociada, XML Schema, permite definir tipos de documentos y los conjuntos de etiquetas necesarios para codificar tales tipos de documentos. La idea es que, una vez los documentos están marcados o codificados con un conjunto de etiquetas XML es posible procesarlos y explotarlos de forma automática con diversos propósitos, de la misma manera que un conjunto de registros de una base de datos se puede explotar de formas diversas, e incluso exportarse a diversos sistemas de gestión de bases de datos si la estructura de registros sigue algún tipo de estándar.

Uno de estos propósitos del uso de XML es codificar los documentos una sola vez, pero poder mostrarlos a través de distintos dispositivos: un navegador de Internet como puede Mozilla o Explorer, la pantalla de una PDA, la pantalla de un móvil, etc., manteniendo siempre el mismo conjunto de etiquetas pero aplicando cada vez una hoja de estilo distinta. Otros propósitos pueden ir desde el uso en Data Mining (minería de datos, si se dispone de un conjunto suficiente de documentos) hasta la recuperación de información. XML es, por tanto, un meta lenguaje de marcado que, por un lado proporciona la posibilidad de codificar páginas de un modo directo con etiquetas ad-hoc y, por otro, proporciona la posibilidad de definir esquemas y tipos de documentos que, a su vez, permiten crear instancias de documentos cuya adecuación puede ser validada de forma automática con programas informáticos.

Con XML podemos diseñar lenguajes de marcado muy estructurados y muy explícitos en los cuales, en lugar de etiquetas como <b> o <i>, podemos disponer de etiquetas como <título>, <subtítulo>, <capítulo>, <autor>, <institución>, <ciudad>, etc. De este modo, si una empresa o institución necesita almacenar y procesar información sobre los currículum vitae de sus empleados, puede desarrollar un Schema XML que le permita crear documentos XML bien formados que dispongan de etiquetas como <lugar_nacimiento>, <titulación_académica>, <idiomas_hablados>, <experiencia_laboral>, etc. XML puede ser visto, a la vez, como un formato de publicación que permite crear lo que algunos autores denominan text-centric documents,

129

puede ser visto como un sistema de intercambio y procesamiento de datos que permite crear en este caso lo que se denomina data-centric documents.

Como sistema de edición y publicación es un formato que utilizan ya numerosas aplicaciones ofimáticas. La más importante en el mundo del software libre es la desarrollada por Sun Microsystem, OpenOffice. Las dos siguientes ilustraciones muestran una captura de un texto editado con OpenOffice y el código fuente del mismo texto generado en formato XML de forma automática por OpenOffice:

Figura 65. Pantalla capturada del OpenOffice.

130

Figura 66. Parte del código XML utilizado por Sun para crear la pantalla de OpenOffice.

Comentemos algunas observaciones sobre las dos figuras anteriores: en primer lugar, el uso que hace OpenOffice de XML es transparente al usuario, es decir, éste no necesita saber nada sobre XML ni siquiera se abruma al usuario informándole sobre este formato salvo que el usuario desee bucear en las interioridades técnicas del programa. En segundo lugar, OpenOffice permite guardar documentos en distintos lenguajes o aplicaciones XML, entre ellos, el formato DocBook para codificar libros y documentos técnicos y el formato XML de las aplicaciones de Microsoft Office. Por último, como podemos ver un documento codificado con XML guarda enormes semejanzas con el código fuente HTML de una página web.

El motivo es que ambos lenguajes, HTML y XML, derivan del mismo metalenguaje, el denominado como SGML. Estas son las siglas de Standard Generalize Markup Language,un lenguaje desarrollado por IBM en la década de los 70 y que actualmente es una norma ISO para el marcado de documentos. De esta norma proceden lenguajes como HTML, XHTML o XML,de forma que comparten la misma filosofía básica y la forma de actuación idéntica: los documentos consisten en texto rodeado por parejas de marcas especificas (como las que conocemos en el caso de HTML: <h1>… </h1>, <p>… </p>), con una de ellas actuando como inicio de la marca (<h1>) y otra como final de la marca (</h1>).

Miller y Clarke (2004) examinan las características que hacen de XML un estándar especialmente importante para el mundo de la Biblioteconomía-Documentación y las agrupan en tres ejes principales:

1. No propiedad / Interoperabilidad / Neutralidad de plataforma.

2. Longevidad / Persistencia / Utilización futura.

3. Separación de contenido, visualización y funcionalidad / Reutilización.

El primer eje (No propiedad, etc.) se refiere al hecho de que XML es un sistema abierto, no propietario e independiente de la plataforma, es decir, independiente tanto de sistemas operativos (Windows, Unix, etc.) como de ordenadores concretos (PC, Macintosh, Sun, etc.). Esto significa que puede funcionar exactamente igual en todos ellos. El segundo (Longevidad, etc.)

131

incide en los aspectos, tan propios del mundo bibliotecario y archivístico como es la preservación de la información. En realidad, esta faceta de XML deriva directamente de la primera: puesto que la información codificada en XML es independiente de la plataforma, el código fuente puede interpretarse directamente por el ojo humano, estando su persistencia y conservación garantizadas para el futuro. Por último, el tercer eje (Separación de contenido, etc.) afecta en uno de los aspectos más interesantes e inteligentes de XML: separar el marcado del contenido de su presentación. XML es un instrumento de primer orden para procesar información. La información pueden almacenarse en un único formato y reutilizarse en tantos formatos como sea necesario: HTML, PDF, página web, documento impreso, monitor de ordenador, PDA, etc.

Lo cierto es, que ya de por sí, cada uno de los tres ejes mencionados justificaría por sí solo el uso de XML en el mundo de la biblioteconomía-documentación. Por el momento, entre las aplicaciones de XML en el mundo de las bibliotecas digitales podemos mencionar proyectos como el liderado por la Library of Congress para migrar el formato MARC al entorno XML (www.loc.gov/standards/marcxml/), o el de hacer lo mismo con el formato de codificación de archivos EAD (Encoded Archival Description). La inmensa mayoría de los proyectos actuales de bibliotecas digitales que se están desarrollando en diversos ámbitos temáticos y geográficos se apoyan, en más de una forma, en el uso de XML, bien sea por la forma de codificación de la información, con formatos como TEI o DocBook o bien sea por la forma de codificación de los metadatos de cada documentos, con formatos como Dublín Core expresado en XML/RDF.

Por último, podemos señalar el movimiento Open Access como otra de las formas más interesantes en las cuales XML tiene incidencia en el mundo de la documentación. En este caso en el mundo de la información y documentación científica a través de los repositorios creados por diversas instituciones, particularmente, universidades de artículos, informes y resultados de investigación gracias al movimiento Open Archives Initiatives (www.openarchives.org/).

1.5.2. METADATOS Y RDF

El segundo gran componente de la Web semántica son los metadatos, la tercera capa en el diagrama de Berners-Lee. Los metadatos son información sobre la información (o datos sobre datos), de manera que podemos considerar, tal y como ya hemos hecho anteriormente, los catálogos de las bibliotecas como una clase de metadatos ya que informan sobre los documentos disponibles en la biblioteca.

132

Figura 67. Típico registro bibliográfico consistente en un conjunto de metadatos, señalados por flechas. Base de datos de LISA.

En el lenguaje documental clásico se habla de documentos secundarios y de documentos primarios mientras que en la terminología propia de la web hablamos de recursos y de metadatos. En ambos casos estamos delante de información sobre la información (o de datos sobre datos). La tabla siguiente ilustra esta relación.

Tabla 9. Relación entre la terminología clásica y la web.

Ahora bien, la Web semántica ha puesto de manifiesto que, para diversos colectivos existen diversos tipos de metadatos. Por ejemplo, para algunos documentalistas los metadatos son, sobre todo, los datos que ayudan a la recuperación de información (como las palabras clave que se usan para indizar un documento) mientras que otros piensan que los metadatos son sobre todo descriptivos (como la fuente, la autoría o la fecha de publicación). Además de estas diferencias de enfoque (que no obstante se complementan entre sí) existen diferencias de sector. Por ejemplo, un archivo de imágenes de arte necesita un conjunto de metadatos distinto del que necesita un repositorio de tesis doctorales. Las diferentes funciones que cumple un documento añaden nuevas necesidades que deben ser descritas por los metadatos: según el contexto, se requieren metadatos sobre propiedad intelectual, sobre necesidades técnicas de reproducción o sobre condiciones de conservación.

133

Por otro lado, en el desarrollo de la Web semántica se sigue con una cierta tradición documental consistente en extender el alcance de los metadatos hasta el concepto de recurso. De acuerdo con esta idea, un recurso no solamente puede ser un documento, sino que las personas o los objetos materiales también pueden ser considerados recursos, y por tanto pueden ser descritos por los metadatos. Esto hace que se requieran de conjuntos de metadatos también para estos tipos de entidades. El estándar utilizado que permite utilizar metadatos para describir recursos (típicamente sitios web) recibe el nombre de Resource Description Framework (RDF).

Ahora bien, el proyecto de la Web semántica, en lugar de intentar proponer conjuntos concretos de metadatos para todos los propósitos y contextos imaginables (misión que, sin duda, acabaría en fracaso), propone un sistema abstracto de validez universal que debe servir para expresar cualquier conjunto, presente o futuro, de metadatos. Todo el sistema RDF parte de tres entidades lógicas básicas: recursos, propiedades y valores. Con los tres elementos anteriores podemos formar declaraciones o estamentos, sobre recursos del tipo: el recurso X tiene la propiedad Y con el valor P. La tabla siguiente expresa las equivalencias de los componentes básicos de RDF:

Tabla 10. Equivalencia lógico-lingüística en una declaración RDF.

Los recursos no sólo serán sitios o páginas web, sino que también podrán ser cosas que no están en la web, ya sean personas o cualquier objeto del mundo real o conceptual. Las propiedades son las características relevantes de los recursos. Por ejemplo, en relación a las páginas web, el autor y el idioma son dos características relevantes de la misma en casi cualquier contexto y, por tanto, son dos de los atributos típicos a la hora de representar sitios web. Por último, los valores son los datos en los que se concreta un atributo determinado de un recurso determinado. Veamos, por ejemplo, la forma en que Artifact presenta metadatos sobre AllMovie.

134

Figura 68. Descripción de una página Web. Es recurso está rodeado por un circulo, los metadatos marcados mediante flechas.

La figura anterior, tomada de Artifact (www.artifact.ac.uk) muestra una serie de metadatos sobre AllMovie (base de datos comercial que contiene información sobre estrellas de cine, películas, bandas sonoras etc). Observando detenidamente los metadatos, podemos ver que pueden ser expresados según el modelo RDF sin ningún problema:

Tabla 11. Metadatos de Artifact sobre AllMovie basados en una estructura de tripletas.

En realidad, esta forma que utiliza RDF de describir la realidad es bastante similar a como hablamos los seres humanos. Si decimos el “coche cuyo color es rojo”, o “el libro cuyo autor es Umberto Eco” lo que estamos haciendo es describir una realidad usando la misma estructura que RDF. Lo que sucede es que, en realidad, nadie habla así, más bien nos referimos simplemente “al coche rojo” o “al libro de Umberto Eco”, con lo cual la estructura de tripletas pasa desapercibida, ya que no incluimos el nombre del atributo, sino directamente su valor. La cuestión es que los ordenadores no pueden procesar de esta forma la información y debe hacerse explícito el nombre del atributo. Originalmente, la representación de RDF fue concebida en forma de grafos (un sistema de diagramas de inspiración matemática), de manera que los recursos tenían forma

135

de elipse, el atributo en forma de flecha y el valor del atributo en forma de rectángulo. De este modo, el título de un sitio empleando la norma se representaría mediante de la siguiente manera:

Figura 69. Espacio web representado a modo de grafo.

Este sistema gráfico empleado por RDF representa el recurso mediante un cuadrado, que se identifica con una URI correspondiente (en este caso, un URL). El nombre de la propiedad (dc.title) también necesita un URI que, en este caso hemos representado simplemente por dc.title para simplificar (el URI completo sería otro URL tal como “http://purl.org/dc/elements/1.1/dc.title”). Finalmente, el valor de la propiedad es un texto o una cadena de caracteres (“All movie guide”). Naturalmente, no es muy práctico describir miles de recursos, cada uno de ellos con decenas de atributos mediante grafos. Por este motivo, pronto sugirieron formas de expresar estos grafos virtuales mediante una codificación en líneas de texto, operación que recibe el nombre de serialización. Por ejemplo, la tabla siguiente muestra la misma información que el grafo anterior, pero serializada (en este caso, usando RDF/XML y Dublín Core):

Figura 70. Serialización del grafo de la figura 69.

Creo que sería interesante destacar la enorme semejanza de un conjunto dado de metadatos RDF con la tabla de una base de datos relacional. En la siguiente tabla se muestra esto mismo que hemos comentado, con los metadatos de RDF de Artifact sobre AllMovie:

Tabla 12. Metadatos representados como una base de datos relacional.

136

En efecto, en el modelo relacional, cada entidad es una fila de una tabla, y cada columna es un atributo de la entidad. En la siguiente tabla podemos ver las equivalencias entre ambos modelos.

Tabla 13. Equivalencia entre modelos.

Cabe señalar un aspecto muy importante sobre RDF que no siempre es bien entendido. Aunque la inspiración inicial nació en relación entre los metadatos y la descripción de recursos, tal como hemos comentado en las páginas anteriores, lo cierto es que RDF tiene aplicaciones muy diversas. En primer lugar, la imagen que se tiene sobre los metadatos es la que responde al conocido esquema documento secundario > documento primario, donde el documento secundario consiste en un conjunto de pares propiedad/valor (conjunto de propiedades y sus valores correspondientes) que describen al documento original y la relación consiste en que el documento secundario describe al primario. Pongamos por ejemplo un artículo en una revista, este se consideraría como un documento primario, mientras que como documento secundario podríamos considerar el correspondiente registro en una base de datos bibliográfica, en la cual se describe el artículo. Gráficamente se muestra esta relación entre documentos primarios y secundarios en la figura 71. En segundo lugar, para muchos documentalistas, los metadatos siempre describen documentos, y si hablamos de la Web, entonces los metadatos siempre describen páginas (o sitios) web.

Figura 71. Representación de la relación entre documentos primarios y secundarios.

137

Para comprender el verdadero alcance de RDF cabe señalar que este modelo ambas suposiciones quedan desbordadas ampliamente: por un lado, el concepto de metadato en la Web semántica no se restringe al concepto de la descripción (o representación) de algo. Para la Web semántica, una determinada estructura de información es una clase de metadatos.

Por ejemplo, la estructura concreta de la información mediante la cual las compañías de aviación registran información sobre sus vuelos, rutas, asientos ocupados, asientos disponibles, etc., son metadatos. En este caso, los metadatos son la estructura de pares atributo/valor que sirven para registrar una actividad del mundo real: datos sobre vuelos, reservas de asientos, etc. Este espíritu, procedente del mundo de la ingeniería de software, está presente en RDF y es el que explica su semejanza con el mundo de las bases de datos relacionales.

Por otro lado, para el modelo RDF las clases de recursos que se pueden describir no se agotan en las páginas web, más bien todo lo contrario, este no es más que el comienzo. En RDF cualquier cosa que se pueda nombrar o señalar de manera específica (esto es, cualquier cosa que tenga una forma inequívoca de ser identificada) es un recurso. Por tanto, los libros impresos son recursos para RDF desde el momento que tienen un ISBN, las personas son recursos desde el momento en que tienen un número de DNI (o de pasaporte, o de seguridad social), las empresas son recursos desde el instante en el que se le asigna un número de identificación fiscal, etc. En general, cualquier cosa es susceptible de ser tratada en RDF. En último extremo, si no disponemos de una identificación previa para “la cosa”, podemos asignar nosotros mismos una identificación arbitraria, con la única condición de que sea única.

Hoy por hoy, no podemos saber cómo evolucionará la aplicación de estos conceptos de RDF a la hora de su aplicación al mundo práctico. Sin embargo, podemos decir que, por el momento, no parecen afectar al trabajo característico de la Documentación. El motivo por el que los hemos comentado no es otro que el de ayudar a entender algunas características de RDF que, de otro modo, parecen innecesariamente crípticas. Afortunadamente, esta amplitud de miras de RDF no es un obstáculo para su aplicación al mundo de la documentación, sino todo lo contrario: una de las más importantes y significativas aplicaciones de RDF consiste en la descripción de recursos digitales utilizando la norma Dublin Core ( que se comentará extensamente en otro punto de este documento). Norma que, como es sabido, consiste precisamente en aplicar la filosofía documental indicada antes mediante el uso de los metadatos Dublín Core, los cuales son descripciones al más puro estilo bibliográfico (título, autor, fecha de publicación, palabras clave, etc.), es decir documentos secundarios aplicados a sitios web (documentos primarios).

1.5.3. ONTOLOGÍAS

El término ontología ha gozado de varias vidas. Originalmente, el término provenía de la filosofía clásica y en ese contexto, la ontología era una parte de la metafísica que se ocupaba de estudiar la naturaleza de la existencia. Era una especialidad que gozó del favor de los filósofos casi desde el nacimiento mismo de la Filosofía, ya en la Grecia clásica , aunque el término como tal, “ontología”, aparece en el siglo XVII. La llegada de nuevas corrientes filosóficas de finales del siglo XIX, de corte anti metafísico, hicieron que el término perdiera gran parte de su vigencia fuera de algunas escuelas de pensamiento minoritarias o muy especializadas.

138

Sin embargo, mucho después, tanto el colectivo de los informáticos, como el colectivo de los lingüistas , rescataron el término para darle significados distintos y lo incorporaron al lenguaje de la ciencia. En particular, los estudios de Inteligencia Artificial recuperaron el término para designar esquemas conceptuales formalizados sobre algún aspecto de la realidad, con la finalidad de facilitar su reutilización en diferentes contextos o la comunicación entre diferentes sistemas, casi siempre con el telón de fondo de la construcción de sistemas expertos.

En el campo de la terminología apareció también el uso del término ontología. En este caso para referirse a una clase de compilaciones léxicas donde además de indicar la clase de cada término (verbo, nombre, etc.) se indican también las relaciones de sinonimia y se establecen árboles conceptuales que presentan las relaciones jerárquicas y de inclusión entre términos (hipónimos, hiperónimos, homónimos, merónimos, etc.). En este caso, el objetivo de las ontologías para los lingüistas solía ser la creación diccionarios y enciclopedias. Por último, aparecieron usos ocasionales del término en ámbitos dispares.

Por ejemplo, los responsables de Yahoo denominaron ontología a su sistema de clasificación. No es extraño por tanto que también se diera un uso incipiente (y bastante dubitativo) en Ciencias de la Documentación para referirse a algunos lenguajes documentales. Por ejemplo, en algunas ocasiones, MESH, (el tesauro de medicina de la Biblioteca Nacional de Medicina de EE.UU.) ha sido presentado como una ontología.

En los últimos años, el proyecto de la Web semántica ha servido para asentar lo que podríamos denominar el uso “moderno” del término ontología. Este uso actual, como no podía ser de otra forma, está muy cercano al que tenía el concepto en el campo de la Inteligencia Artificial, aunque ahora lo observamos bajo una perspectiva nueva, la de la Web semántica. En este nuevo contexto, una de las definiciones más citada es la debida a Gruber (1993) según la cual una ontología es “la especificación de una conceptualización”. Ahora bien, para entender esta definición tan afortunada, pero a la vez tan compacta que dificulta su entendimiento, vale la pena acudir a la fuente original (muy citada pero probablemente muy poco consultada):

“Un cuerpo de conocimiento formalmente representado, se basa en una conceptualización: los objetos, conceptos y otras entidades cuya existencia se presume en área de interés, así como las relaciones que mantienen entre ellas”. (Gruber, 1993: 2).

Esto viene a decirnos: para representar un cuerpo de conocimiento, primero debemos conceptualizarlo. Para ello se especifican las entidades que forman parte de ese cuerpo y posteriormente se especifican las relaciones existentes entre tales entidades. Atendiendo a esta definición, es de vital importancia conocer el significado de “conceptualización”. Para ello Gruber indica:

“Una conceptualización es una abstracción, una visión simplificada del mundo que queremos representar para algún propósito. Cada base de conocimiento, cada sistema basado en conocimiento, o cada agente de conocimiento está comprometido con alguna conceptualización, implícita o explícita”. (Gruber, 1993: 2).

Partiendo de estas dos conceptos expresados por Gruber, cuerpo de conocimiento y conceptualización, es cuando la famosa definición expresada anteriormente adquiere sentido. Definición según la cual una ontología “es la especificación de una conceptualización”. El gráfico

139

siguiente presenta un ejemplo de clases y subclases de una ontología sobre periféricos de ordenador. Este simple gráfico nos ayudará a entender mejor el concepto de ontología, desde el punto de vista que aporta Gruber, y que retoma el proyecto de la Web Semántica.

Figura 72. Representación de una ontología de periféricos de un ordenador.

Actualmente, en el contexto de la Web semántica, una ontología presenta las siguientes características:

● Se refiere siempre a un dominio concreto del conocimiento. De hecho, se han desarrollado ontologías para sectores tan diversos como las pizzas y las ciencias de la vida; el derecho de autor y la astronomía, los medios de comunicación y el periodismo, etc. El sitio web del proyecto DAML para el desarrollo de ontologías ofrece un directorio de ontologías que a inicios del 2006, presentaba casi trescientas (www.daml.org/ontologies/).

● En segundo lugar, los componentes de la ontología y sus relaciones entre ellos están concebidos en clave de lógica formal utilizando los conceptos de: clase (por ejemplo, la clase de los “discos duros”), propiedades (por ejemplo, “capacidad de almacenamiento”) e individuos (por ejemplo, el disco duro marca “Maxtor DiamondMax11”). Además, una ontología describe la relaciones entre los componentes: individuos con clases, o sea la relación “x es una instancia de y” (por ejemplo: “Maxtor DiamondMax11 es un disco duro”); individuos con propiedades, o sea, la relación “x tiene el valor y para la propiedad p” (por ejemplo, DiamondMax11 tiene el valor de “500GB” para la propiedad “capacidad de almacenamiento”); y clases con propiedades, o es decir, relaciones de restricción (por ejemplo, los discos duros no son separables de la unidad central de las unidades de memoria USB).

● En tercer lugar, a diferencia de la idea que imperaba en la IA “clásica” (inteligencia artificial), la ontología debe estar codificada en un lenguaje compatible con el entorno abierto y descentralizado característico de la Web. Esto implica un doble requerimiento: por un lado que la ontología esté codificada en el lenguaje propio de la Web semántica (OWL) para que pueda ser (re)utilizada a través de diversos sistemas, en diversos contextos y por parte de agentes de usuario heterogéneos. Por otro lado, implica que las

140

ontologías estarán publicadas y disponibles en ordenadores (servidores) interconectados en la Web.

1.5.4. OWL OWL (Web Ontology Language) es el lenguaje estándar que la Web semántica utiliza

para expresar y codificar ontologías. De acuerdo con el W3C podemos decir de OWL:

“OWL está concebido para ser utilizado cuando la información contenida en los documentos necesita ser procesada por aplicaciones informáticas, en oposición a las situaciones donde el contenido solamente debe ser presentado a seres humanos. OWL puede ser utilizado para representar explícitamente el significado de términos en vocabularios y las relaciones [semánticas] entre esos términos (http://www.w3.org/TR/2004/REC-owl-features20040210/)”.

OWL permite formalizar las relaciones entre las clases, aún más que el RDF Schema, para ello indica aspectos básicos para el razonamiento, como la existencia de clases disjuntas. Por ejemplo: “los periféricos de salida no son periféricos de almacenamiento”, esto es, la clase de los periféricos de salida forman un conjunto disjunto de los periféricos de almacenamiento. También permite expresar la cardinalidad, es decir, el número de elementos que pueden componer una clase, por ejemplo, “un libro puede tener uno o varios autores” (la cardinalidad de los autores de un libro es uno o más de uno), o bien “un libro solamente puede tener un ISBN” (la cardinalidad del ISBN de los libros es exactamente uno). Puede expresar igualdad o equivalencia entre clases, características y restricciones de las mismas, etc.

OWL utiliza RDF/XML para representar y codificar las ontologías. OWL sigue la tendencia tan característica del W3C de proceder mediante “extensiones”. Por tanto, OWL es una extensión de RDF que añade elementos como los mencionados anteriormente para describir características y clases. A modo de ilustración, en la figura siguiente podemos ver parte de la ontología anterior sobre periféricos de ordenador, pero ahora representada en OWL:

Figura 73. Representación en OWL de la ontología anterior.

141

Podemos ver por el ejemplo anterior que un documento OWL es, ante todo un documento XML tal como se declara en la primera línea de la ontología (<?xml version=”1.0”>). A continuación, el ejemplo anterior nos muestra también que el elemento raíz de la ontología es el elemento RDF (rdf:RDF). La idea esencial es que en algún momento del futuro, pero no antes del 2010, la Web estará poblada por un número de ontologías que permitirán a los ordenadores realizar inferencias sobre la información publicada en la Web. Estas ontologías podrán estar publicadas en los mismos servidores que sirvan para publicar las páginas web o en servidores específicos compatibles con la arquitectura de la Web.

En este sentido, cabe señalar que algunas previsiones sitúan el desarrollo de la Web semántica, incluyendo la última capa (Proof), no antes del 2012. Como las ontologías están situadas casi en la parte superior de este modelo de capas, es por ello que nosotros indicamos “no antes del 2010”. No obstante, por motivos que argumentaremos a continuación es posible que incluso esa fecha resulte demasiado optimista y el uso efectivo de ontologías se retrase de manera indeterminada mucho más allá de las fechas barajadas hasta el momento.

2. METADATOS Y LA INICIATIVA DVB-H

2.1. INTRODUCCIÓNEn la actualidad pasamos gran parte del día cargados con pequeños dispositivos

como PDA’s o teléfonos móviles que en principio tenían una finalidad muy concreta, pero con el avance de la tecnología su funcionalidad ha ido aumentando. Por ello, hoy en día estos dispositivos no se limitan únicamente al objetivo original para los que fueron creados, sino que su campo de uso se ha abierto.

Si nos fijamos en el caso de los teléfonos móviles, la misión con la que fueron ideados fue la de poder mantener conversaciones telefónicas desde cualquier punto sin tener que estar conectados físicamente con un cable que nos limitara las posibilidades de movilidad. Sin embargo, esa idea inicial no tiene nada que ver con lo que hoy en día se puede entender por teléfono móvil y en la actualidad parece casi imposible entender un dispositivo de este tipo que tuviera simplemente esa funcionalidad. Se fueron añadiendo funciones como aplicaciones de agenda, calendario, calculadora, muchos lo usan en la actualidad como despertadores. Posteriormente surgieron en ellos aplicaciones de tipo multimedia, como son los juegos o la posibilidad de reproducir imágenes en color o vídeos, se introdujeron en ellos pequeñas cámaras fotográficas de baja resolución, se les dotaron de la posibilidad de funcionar como dispositivos para la reproducción de música, conexión a Internet, etc. Podríamos seguir con una lista interminable de usos, pero si alguno nos interesa en este momento es la posibilidad de ver la televisión en estos dispositivos.

Como ya hemos dicho, éstos son dispositivos que nos acompañan allí donde vayamos, de forma que allá donde nos movamos es casi seguro que llevaremos con nosotros nuestro teléfono móvil, tanto en nuestro movimiento diario como en viajes más largos. Esto se debe precisamente al pequeño tamaño, lo cual se convierte en este caso, en una ventaja para su uso aunque un problema en otros aspectos. Por lo tanto, parece lógico que intentemos integrar en

142

su interior todo aquello que nos puede hacer falta en la vida cotidiana. Sin embargo, no sólo debemos limitarnos a las aplicaciones estrictamente necesarias o que nos puedan ser útiles para el trabajo, sino que también se puede convertir en un elemento de diversión o distracción. En este conjunto de servicios es en el que se puede incluir el uso del teléfono móvil para ver la televisión.

La idea de poder ofrecer los servicios de la televisión en dispositivos de bolsillo es una idea que no parece nueva sino que se trata de algo que lleva en mente de muchas personas desde hace un tiempo. Sin embargo, existen una serie de limitaciones que hacen que esto no se haya podido llevar a cabo hasta la actualidad, casi todas ellas heredadas del pequeño tamaño de este dispositivo, convirtiéndose el tamaño en su mayor aliado y en su máximo enemigo de forma simultánea. Este pequeño tamaño introduce limitaciones en lo que se refiere a la visión, ya que la pantalla de un dispositivo de bolsillo tiene unas dimensiones muy reducidas con una resolución muy baja, lo que provoca que no sea algo cómodo ver imágenes en móviles o PDA’s. Sin embargo, en las últimas fechas parece existir una tendencia a la aparición de modelos con un tamaño de pantalla algo más grande, ayudando por lo tanto a su visión, por lo que es recomendable el uso de este tipo de aparatos para ver la televisión. Además, del pequeño tamaño también heredamos otros problemas como son la escasa potencia de cálculo y de lógica que poseen o la escasa posibilidad de manejo que tiene el usuario, que sólo podrá comunicarse con el dispositivo a través del teclado alfanumérico.

Debido a este interés desde hace tiempo han ido surgiendo una serie de implementaciones o de sistemas que han intentado poner en práctica una televisión para equipos de bolsillo. Algunos de estos estándares que han ido surgiendo o con los cuales se puede implementar un sistema de televisión son los que se recogen en la tabla siguiente:

Figura 74. Comparativa de sistemas de televisión en movilidad.

En esta figura se puede observar una comparación entre 5 sistemas que tratan de ofrecer el servicio de televisión sobre dispositivos móviles. Como se puede observar, el único que tiene un carácter mundial es el estándar DVB-H, mientras que los otros han sido adoptados únicamente en algunas regiones del mundo. Esta es una de las principales ventajas de DVB-H sobre el resto de los sistemas, ya que lo que sea desarrollado para DVB-H en un lugar del mundo

143

podrá ser utilizado en cualquier otro lugar del mundo, cosa que no ocurre con los demás sistemas.

Además, DVB-H surge del estándar DVB-T, conocido en España como TDT, con una compatibilidad bastante importante con dicho estándar, lo que supone que no será necesario instalar una nueva red completa, sino que se podrá hacer uso de los sistemas que ya existen instalados. Ésta también resulta una ventaja bastante interesante, ya que el desembolso económico inicial para comenzar a obtener beneficios será mucho menor y por lo tanto se obtendrán mucho más rápido. Otras ventajas menos importantes sobre el resto de los sistemas pueden ser la cantidad de canales diferentes que es capaz de soportar o la calidad de la imagen que nos puede ofrecer.

Para saber las opciones que tiene de triunfar DVB-H se han hecho varias pruebas pilotos en distintos lugares del planeta arrojando resultados que son bastante sorprendentes y que pueden servir a las proveedores de servicio para saber lo que es más demandado por los usuarios, así como los contenidos que son más solicitados o aquellos que tienen un mayor número de espectadores. De entre los resultados obtenidos en las pruebas piloto que se han ido realizando en distintos lugares del mundo podemos destacar algunos resultados interesantes:

● Tras la realización de las pruebas el 75% de los usuarios que tuvieron ocasión de disfrutar del servicio recomendarían el uso del mismo a otras personas que nunca hayan usado el sistema.

● De esos usuarios que tuvieron la ocasión de probar los servicios de DVB-H el 55% reconoce que seguiría usando el servicio de televisión móvil aunque ello supusiera tener que pagar para poder verlo.

● El tiempo medio que los usuarios dedicaban a ver la televisión en el móvil a lo largo del día era de aproximadamente 16 minutos.

● El 48% de los usuarios reconocen que la mayor parte del tiempo hacían uso del servicio en su casa, debido fundamentalmente a que la oferta de canales y de servicios era mayor incluso en DVB-H que en la televisión de la casa. Otros de los lugares más habituales para ver la televisión en el móvil era en los trayectos hacia el trabajo o en los descansos del mismo.

● El 58% de los encuestados prefería que los contenidos ofrecidos se adaptaran a las características especiales de los dispositivos móviles, de forma que preferirían que los contenidos fueran de una duración menos que los de la televisión tradicional y que los principales programas ofrecidos fueran fundamentalmente informativos, series y programas.

1.1. COMPARACIÓN ENTRE DVB-H Y DMB

En la actualidad los dos sistemas para la implementación de sistemas de telefonía móvil más extendidas en el mundo son DVB-H y DMB. Existe un tercer sistema en el grupo, pero con un menor nivel de aplicación y que es ofrecido por la empresa estadounidense Qualcomm. DVB-H es un estándar que está prácticamente extendido por todo el planeta, aunque DMB está

144

siendo el mayoritario en Corea del Sur y ha sido implementado por algunas empresas europeas también.

Sin embargo, DVB-H aparece como el sistema con una mayor capacidad de triunfo y unas posibilidades mayores de llevarse el gato al agua en lo que a éxito en el mercado se refiere. De hecho, la unión europea ha anunciado que tiene la intención de que DVB-H se convierta en el estándar mundial para la visualización de televisión en los dispositivos móviles, instando a los fabricantes a que lo implementaran en sus equipos cuanto antes. En los últimos tiempos ha sido reiterada esta postura e incluso se ha anunciado la posibilidad de decretar el uso de DVB-H como el estándar universal en vista de una posible falta de acuerdo entre las distintas compañías. Todo esto hace del uso de DVB-H una apuesta segura en el desarrollo tanto de aplicaciones como de sistemas para su implantación.

Por otro lado, no hay que perder la perspectiva de que existen otras formas de ofrecer televisión móvil, así que presentamos aquí una pequeña comparación entre los dos sistemas, viendo las características en las que uno puede superar a otro:

● Ancho de banda: DVB-H tiene un mejor ancho de banda un mejor comportamiento en lo que a ancho de banda se refiere.

● Modulación: DMB es superado por el otro sistema en 3 dB.

● Corrección de errores: MPE-FEC nos aporta una ventaja adicional en lo que se refiere al canal.

● Velocidad: DVB-H ofrece mayor capacidad y flexibilidad.

● Escalabilidad: en el futuro se prevee que DVB-H pueda crecer más rápido y en mayor medida.

● Sistema de multiplexión por división en el tiempo: el ahorro en el consumo ofrecido por DMB es menor que el ofrecido por su competidor.

● Protocolo: DVB-H ofrece una mayor flexibilidad con el protocolo IP.

2.2. ARQUITECTURA Y FUNCIONAMIENTO DE DVB-HDVB-H es la tecnología estándar global líder en la transmisión digital de televisión para

receptores móviles tales como teléfonos móviles y PDA's. Fue publicado por el ETSI en Noviembre de 2004 y se trata de una especificación de capa física diseñada para permitir la entrega eficiente de datos encapsulados en IP sobre redes terrestres. La creación de DVB-H, que está íntimamente relacionada con DVB-T, también supone modificaciones de otros estándares de DVB en relación con la difusión de datos, información de servicios, etc. Está diseñada para ser usada como guía en unión con un conjunto de especificaciones físicas de sistemas DVB-IPDC (IP Datacasting Over DVB). Se trata de un estándar abierto y no propietario, que ha tenido una gran acogida por la industria y que ha sido objeto de más de una treintena de implementaciones técnicas y comerciales alrededor del mundo.

Cuando se discutió por primera vez la posibilidad de una especificación DVB especial para difusión a terminales móviles, era en el contexto de una excelente especificación DVB-T, que

145

había supuesto un éxito en cuanto a lo que se refiere a televisión digital terrestre. Los objetivos claves a conseguir eran la televisión móvil, el flujo de vídeo en general y la descarga de archivos, todo ello orientado a dispositivos receptores móviles que operarían con un tiempo de vida de la batería bastante corto y unas condiciones para la recepción bastante complicadas. Lo más importante era que debería haber un ahorro de batería bastante importante en los receptores en comparación con el estándar DVB-T.

Se puede considerar DVB-H como una extensión de DVB-T con cierta compatibilidad hacia atrás, como que puede compartir multiplexor con DVB-T. Usa un mecanismo de encapsulación denominado MPE (Multi-Protocol Encapsulation) haciendo posible el transporte de protocolos de redes de datos sobre flujos MPEG-2. Se usa un esquema de corrección de errores denominado FEC (Forward Error Correction) unido con mejoras en la robustez y por tanto la capacidad de obtener la señal en movilidad. Otra de las características fundamentales de DVB-H es lo que se denomina Time-Slicing (podría traducirse por algo como ‘tiempo ranurado’), que es la principal técnica usada en este estándar para conseguir el ansiado ahorro de energía tan necesario para el éxito de DVB-H. Cada uno de los servicios en la señal DVB-H se transmite en ráfagas permitiendo al receptor entrar en un estado de ahorro de energía, despertando únicamente cuando el servicio al que desea acceder está siendo transmitido. Para los dispositivos móviles esto puede suponer un ahorro de energía muy importante. Todo esto se encuentra reflejado en la siguiente figura 75.

Figura 75. Esquema de funcionamiento DVB-H.

Otra de las ventajas fundamentales que posee el estándar de DVB-H es que se encuentra creado y diseñado en conjunción con IPDC (IP DataCast), de forma que es posible que la transmisión de datos IP sobre las redes de DVB-H, con las interesantes aplicaciones que puede tener esto en relación a la transmisión de información adicional sobre las imágenes, información de interés para el usuario final, información de interés para el dispositivo receptor.

146

2.2.1. FUNCIONAMIENTO BÁSICO

Como ya hemos indicado en varias ocasiones a lo largo de este documento los dispositivos móviles poseen una serie de características diferenciales que hacen que lo que sea necesario que para la transmisión y la recepción tanto de datos como de imágenes se deban realizar modificaciones sobre los estándares dominantes para cada una de las áreas. Las características más importantes de este tipo de dispositivos son las siguientes:

● En relación a la batería, el sistema de transmisión debería ofrecer a los receptores la posibilidad de apagar parte de la recepción dándole la oportunidad de incrementar la duración de la misma.

● Los dispositivos no se encuentran siempre en la misma ubicación, sino que se les puede considerar nómadas. Por esto, el sistema de transmisión debería facilitar la posibilidad de acceder a los servicios DVB-H cuando los receptores dejan una celda determinada para pasar a otra celda.

● Debido también a la movilidad intrínseca de estos receptores nos podemos encontrar ante muy diversos entornos, pudiendo encontrarse en interiores, exteriores, en medio del campo o en el interior de un coche en movimiento. En consecuencia el sistema de transmisión debería ser lo suficientemente robusto y escalable como para permitir la recepción de los servicios DVB-H a diferentes velocidades a la vez que se optimiza la cobertura de la transmisión.

● Los servicios DVB-H pueden ser solicitados en medios con gran ruido, así que el sistema debe ofrecernos alguna posibilidad con la que poder reducir este ruido ambiental y sus efectos.

● Los dispositivos móviles, como su nombre indica, son dispositivos que se mueven con sus dueños, es decir, que estos viajan cuando sus usuarios viajan. Por lo tanto, sería interesante que el estándar tenga un carácter global de forma que el usuario pueda seguir usándolo aunque no se encuentre en su lugar de residencia habitual. Esto supone que el estándar desarrollado pueda ser usado en diferentes bandas de frecuencia.

Por consiguiente, el estándar DVB-H debe proveer de todos aquellos mecanismos que fuesen necesarios para obtener los resultados anteriores. Se puede decir que DVB-H es el resultado de la conjunción de elementos de capa de enlace y capa física, entre los que se pueden destacar los que siguen:

1. En la capa de enlace:

● Time-Slicing: se usa para reducir el consumo medio de alimentación por parte del terminal y permitir el cambio de frecuencia con cierta facilidad, facilitando el cambio de celda.

● MPE-FEC: conjunción de corrección de errores (FEC) y de encapsulación multiprotocolo (MPE) con el objetivo de mejorar la relación señal a ruido y el efecto Doppler en los canales móviles, así como para mejorar la respuesta ante el ruido impulsivo.

1. Capa física: se basa en la capa física de DVB-T con algunas pequeñas modificaciones,

147

como la posibilidad del uso de modulación 4K, mientras que en DVB-T se usa de 2K y de 8K. Esto aumenta las posibilidades de este estándar.

2.3. IP DATACAST OVER DVB-H (IPDC)Todo lo visto hasta ahora en el funcionamiento de DVB-H se refiere exclusivamente al

estándar DVB-H y sus diferencias fundamentales con el estándar de la Televisión Digital Terrestre (DVB-T). Las principales diferencias de estos se encuentran centradas en las capas físicas, es decir, que se encuentran centrados en la forma en la que las cosas van a ser transmitidas, cómo ahorrar energía en la recepción o cómo conseguir una mayor robustez tan necesaria en los sistemas de telefonía móvil, con una gran exposición a ser atacados por cualquier tipo de ruido ambiental. Sin embargo, nuestro interés no se centran tanto en las características físicas de DVB-H (las cuales hay que conocer para poder entender el sistema complemente) sino más bien en las nuevas posibilidades de negocio que se abre con el uso de los dispositivos móviles y sus inherentes capacidades de movilidad y de ofrecer un canal de retorno hacia el proveedor de servicios, para así poder ofrecer una experiencia de usuario mucho más atractiva para el cliente final.

Por lo tanto, nos debemos centrar en cómo ofrecer servicios a los clientes y cómo estos serán capaces de acceder a los mismos. En consecuencia, a partir de ahora vamos a alejarnos de todas esas características físicas y ocuparnos de otra serie de problemáticas.

Una de las características que definen el uso de DVB-H es la posibilidad de usar sobre DVB-H la transmisión de paquetes IP que contendrán información sobre los servicios ofrecidos y sobre cual debe ser la forma en la que el usuario interactúe con el sistema para poder tener acceso a los mismos. Esto es lo que se conoce con el nombre de IP Datacast Over DVB-H (o lo que es lo mismo IPDC).

Tradicionalmente las redes de comunicación móviles y de difusión se trataban como redes separadas y cada una de ellas eran implementadas en equipos terminales diferentes. Sin embargo, la mezcla de las dos tecnologías nos ofrece unidas las capacidades de recepción rápida de un flujo de datos de las redes de difusión de datos y la de interactividad de las redes de telefonía móvil. El uso de IP-Datacast nos permite la mezcla de ambas redes con todas las posibilidades extra que acabamos de ver que ello conlleva.

IPDC se basa en la idea de que existe un sistema de difusión (como puede ser DVB-H) que conecta a los sistemas de cabecera con los dispositivos receptores finales. En concreto, DVB-H es uno de los primeros sistemas desarrollados completamente en este sentido, de forma que IPDC está formada por un conjunto de especificaciones que describen todos los componentes que serán necesarios para incorporar DVB-H a un sistema de red híbrida, como puede ser GPRS o UMTS. IPDC se usa por DVB para describir todos aquellos elementos fundamentales que irán sobre DVB-H.

148

Figura 76. Sistema típico de la arquitectura IPDC.

2.3.1. ARQUITECTURA IPDC

IPDC sobre DVB-H involucra un número de entidades funcionales sobre un sistema de puntos de referencia. La figura 77 muestra las entidades funcionales y las relaciones entre ellas.

Las entidades funcionales que aparecen en la arquitectura son:

● Service Application (Aplicación de servicio),

● Service Management (Gestión de servicio),

● Broadcast Network (Red de difusión) y

● Terminal.

Las entidades que están fuera de la especificación DVB-CBMS son:

● Interactive Network (Red interactiva) y

● Content Creation (Creación de contenido).

149

Figura 77. Diagrama de una Arquitectura global que usa IPDC sobre DVB-H.

Se pueden definir las principales acciones que van a producir un servicio, indicando la sucesión de entidades funcionales y relaciones (puntos de referencia) que serán involucradas. En cada punto de referencia se utilizara un determinado protocolo y se realizarán distintas acciones. Para obtener una información más completa se puede acudir al documento de la ETSI TR 102 469, en el cual se describen todas estas entidades funcionales, así como los puntos de referencia. También nos ofrece una visión sobre como deben relacionarse las entidades funcionales para poder ofrecer todos los servicios diferentes.

2.3.2. PILA DE PROTOCOLOS IPDCDVB-IPDC se basa en un conjunto de especificaciones individuales, de manera que

todas juntas forman el sistema completo y se puede decir que IPDC sobre DVB-H posibilita al interacción entre las redes de difusión y red de comunicación móvil (canal de retorno). Esto da lugar a la aparición de una amplia oferta de servicios que hasta ahora eran propios de entornos de redes IP. De manera que usando IPDC la red de radiodifusión de señal DVB-H puede no sólo radiodifundir una señal de televisión a los terminales, sino que puede enriquecerla asociándole unos servicios de valor añadido, creando contenidos interactivos con los usuarios. En las

150

siguientes figuras veremos la pila de protocolos de IPDC y un ejemplo de un servicio interactivo que utiliza IPDC sobre DVB-H.

Figura 78. Pila de protocolo IP-Datacast sobre DVB-H.

Figura 79. Ejemplo de un contenido con un servicio ofrecido con IPDC sobre DVB-H.

Como hemos dicho, la idea de usar IPDC sobre DVB-H es poder no sólo radiodifundir un programa de televisión, sino poder enriquecerlo con unos servicios de valor añadido que ofrezcan entre otras cosas una interactividad entre el usuario y la plataforma. En el ejemplo visto

151

anteriormente, lo que tenemos es un videoclip y la posibilidad de que un usuario pueda descargarse la canción que le apetezca de forma simultánea. Para conseguir esto, podemos distinguir en la torre de protocolos cuatro partes diferenciadas, que trabajando en conjunto, llevarán a cabo el objetivo pretendido. Vamos a dar una breve explicación de cada una de ellas, suponiendo que pretendemos llevar a cabo el ejemplo anterior, donde queremos transmitir un vídeo con audio y permitir la descarga de una canción.

● Parte de Audio y vídeo. El audio y el vídeo de la señal se transportará usando un protocolo RTP (Real Transport Protocol) que se transformará en un flujo de paquetes IP, los cuales serán los encargados de transportar el vídeo y el audio del contenido.

● Parte de servicio de valor añadido. Realmente se corresponde con el fichero mp3,(wav,.alc etc.) con la canción que se pretende ofrecer para descargar. Este fichero pasa por un carrusel FLUTE ( File Delivery over Unidirectional Transport) que de manera periódica dejará la información en la capa IP para que sea transmitida como un flujo de paquetes IP.

● Parte de la ESG (Electronic Service Guide). La guía electrónica de servicios es un fichero que se envía a los terminales móviles DVB-H, y que tiene como principal objetivo informar a cliente sobre los contenidos que se transmiten, como adquirirlos, que servicios tienen asociados, donde poder adquirir cada contenido etc. Esto es, con una ESG en su poder, un terminal móvil debe ser capaz de hacerle ver al usuario qué contenidos se ofrecen y con qué servicios, y permitir que este una haya seleccionado lo que quiere visualizar, pueda adquirir los flujos de paquetes IP correctos donde podrá encontrar la información que ha seleccionado. La generación de estas guías electrónicas de servicios se basan en el uso de metadatos, metadatos que contienen la información que necesitará el cliente del terminal móvil (software que hay en el receptor para interpretar las señales DVB-H) para poder ofrecer a los usuarios los contenidos radiodifundidos en DVB-H. Estos metadatos serán básicamente de tres tipos:

○ Metadatos propios de IPDC.

○ Metadatos del estándar MPEG-7.

○ Metadatos del estándar TV-Anytime.

En los próximos apartados explicaremos más detalladamente qué son las ESGs y que metadatos son utilizados para crearlas. Cabe destacar que la ESG se transmitirá como un fichero más dentro del carrusel FLUTE, donde encontramos en este caso el fichero con la canción a descargar.

● Parte DVB-H. Esta parte se encargará de recoger los flujos de paquetes IP, de vídeo/audio, la ESG y la canción, y los convierte en un flujo de paquetes MPEG-2 que serán radiodifundidos como señales DVB-H, que llegarán a los terminales donde deberán ser interpretadas.

2.4. ESG (ELECTRONIC SERVICES GUIDE)Sabemos que en las transmisiones DVB-H no sólo se pueden radiodifundir contenidos

152

de vídeo y audio, sino también todo tipo de contenidos multimedia, a los que denominamos servicios asociados. Un ejemplo sencillo lo encontramos en los logos que transmitimos junto a los contenidos que ofrecemos. Sin embargo, a parte de esto, en DVBH enviamos información que nos sirve para que el receptor móvil DVB-H pueda adquirir dichos contenidos que estamos ofreciendo, información como el fichero ESG (Electronic Services Guide). Este es un fichero XML basado en metadatos de tres estándares principalmente, IPDC,TVA y MPEG-7. Los terminales móviles utilizan este fichero para poder adquirir y mostrar los contenidos que están siendo emitidos.

Como hemos dicho, una ESG es un fichero XML, que siguiendo el estándar IPDC, permite que los terminales móviles puedan conocer entre otras cosas, qué servicios (para nosotros principalmente serán canales de televisión) se están ofreciendo y bajo que IP se pueden adquirir. Contiene información sobre los servicios ofrecidos a los usuarios, a través de ella el usuario puede seleccionar el contenido en el cual está interesado, visualizarlo y acceder a los servicios multimedia asociados al mismo. Por otra parte la ESG contiene información que será utilizada, por parte del receptor, para poder mostrar al usuario qué contenidos se encuentran disponibles, cuando están disponibles y con qué servicios multimedia asociados los encontramos.

2.4.1. ADQUISICIÓN DE UNA ESG

Hemos comentado que para que un terminal móvil conozca que servicios se están ofreciendo y bajo qué IP, necesita recibir una ESG de la plataforma DVB-H. Por tanto se hace fundamental conocer como el terminal puede adquirir dicha ESG. Para ello, el terminal adquiere de la plataforma dos ficheros, conocidos como Bootstrap, un fichero .bin y un xml.

Estos ficheros vienen a indicarle al terminal móvil qué plataforma DVB-H está transmitiendo la ESG, y bajo que IP lo está haciendo, de manera que este pueda capturar dicha ESG. Los ficheros Bootstrap siempre se radiodifunden bajo una misma IP y un mismo puerto: 193.0.23.14:9214, de manera que cualquier terminal móvil pueda identificarlos fácilmente. Esta información, de cuál es la IP y el puerto del Bootstrap, la extrae el terminal de las tablas PSI/SI, que radiodifunden cada una de las plataformas con información sobre ellas misma y los contenidos que radiodifunden (aquellas personas que hayan estudiado algo de DVB-T pueden pensar que los ficheros ESG son para los terminales DVB-H como las tablas PSI/SI para los terminales DVB-T).

Una vez el terminal tiene en su poder el Bootstrap, podrá adquirir la ESG y actualizarla de forma periódica. Con la ESG adecuada en su poder, el terminal podrá conocer como se acceden a los servicios que la plataforma DVB-H está transmitiendo, así como los contenidos multimedia asociados. Veamos un modelo de adquisición de una ESG y de como se selecciona un servicio, una vez se obtiene la ESG partiendo del Bootstrap.

153

Figura 80. Modelo de adquisición de una ESG y de un servicio

154

2.4.2. ESTRUCTURA DE UNA ESG

Una ESG se compone de una serie de fragmentos (Service, Content, ScheduleEvent...), que pasaremos a explicar cada uno de ellos desde un punto de vista funcional. Posteriormente, en los siguientes apartados, estudiaremos su estructura interna, comentando los metadatos que la componen. En la siguiente gráfica vamos a ver el modelo de datos en el que se basa una ESG, de manera que distingamos los fragmentos de la misma y las relaciones existentes entre ellos.

Figura 81. Modelo de relaciones entre los fragmentos de la ESG.

● Fragmento Service. En este fragmento encontramos las definiciones de los distintos servicios que son radiodifundidos por la plataforma DVB-H. Este fragmento aporta tanto una descripción de los servicios, como información visual asociada a los mismo (un logo por ejemplo). La información podrá ser utilizada por el cliente receptor para atraer la atención del usuario al consumo de un determinado servicio. Además lleva información que utiliza el terminal para que el usuario pueda consumir dicho servicio.

● Fragmento ServiceBundle. Este fragmento es usado para poder agrupar servicios. Es un fragmento opcional que nos da la posibilidad de ofrecer al usuario lotes de servicios. Por ejemplo, si agrupamos varios canales de música en un bundle (40 TV, MTV 40Latino, MTVLatino etc.), un usuario que compre los derechos de ese bundle tiene acceso al consumo de cualquiera de los canales. Simplemente para familiarizarnos vamos a exponer sendas gráficas con la sintaxis y la semántica de los elementos que componen el fragmento. Esto es algo que repetiremos a lo largo de este capítulo, donde pretendemos explicar los distintos fragmentos que pueden formar parte de una ESG.

● Fragmento Content. El fragmento Content aporta metadatos que describen un determinado contenido que está siendo radiodifundido por uno o varios servicios DVB-H. Este contenido puede ser un video, un audio o una aplicación multimedia. En el fragmento Content vamos a tener una referencia a un fragmento Service, para que el usuario pueda identificar ese contenido en que canal de televisión se va a radiodifundir, y una referencia al fragmento ScheduleEvent, que como veremos posteriormente sirve para que el usuario sepa en que fecha y a que hora se va a radiodifundir dicho contenido. De una manera informal, podemos decir que los fragmentos Content y ScheduleEvent, serán los que

155

conformen la EPG de la radiodifusión, de forma que en DVB-H una EPG formará parte de una ESG.

● Fragmento ScheduleEvent. Los fragmentos ScheduleEvent especifican el día y la hora a la cual se va a emitir un contenido asociado a un servicio determinado. Como hemos dicho anteriormente, junto con los fragmentos Content y Service permiten elaborar la EPG de la radiodifusión. El periodo de tiempo que se marca en el fragmento ScheduleEvent, es un periodo de tiempo orientativo, para mostrar al usuario, no implica que obligatoriamente el contenido tenga que estar disponible en esa franja. Los fragmentos Services, Contents y los ScheduleEvent se agrupan bajo etiquetas XML denominadas, ServiceTable, ContentTable y ScheduleEventTable respectivamente.

● Fragmento Acquisition. Básicamente el fragmento Acquisition transporta el fichero sdp. Este fichero lleva la información necesaria para que el receptor pueda adquirir un determinado servicio, o contenido concreto que esté asociado a ese servicio, como un material relacionado (los materiales relacionados los comentaremos a fondo más adelante). De esta manera un fragmento Service tendrá una referencia a un fragmento Acquisition, donde el cliente receptor encontrará un fichero sdp donde se le indicará entre otras cosas porqué IP y con qué velocidad se está radiodifundiendo el servicio. El fichero sdp puede aparece físicamente formando parte del fragmento Acquisition en la ESG, ( modo “inline”) o podemos encontrar una referencia y enviarse como un fichero a parte de la ESG ( modo “outofband”). Veamos un trozo de código de un fragmento Acquisition en una ESG, con una sdp “inline”.

● Fragmento Purchase. El fragmento Purchase es quién llevará la información necesaria para que el usuario conozca cuáles son los servicios que son de pago, qué derechos son ofertados al usuario y la manera que este tiene para adquirir dichos derechos sobre los servicios. El Purchase puede hacer referencia a un servicio en concreto o a un conjunto de servicios agrupados en un ServiceBundle.

● Fragmento PurchaseChannel. Este último fragmento viene a indicar a los usuarios los medios de comunicación a través de los cuales pueden realizar la compra de uno o varios servicios (o contenidos), de los que se están ofreciendo en la plataforma. Esto es, indica se la compra se realiza a través de Internet, un mensaje de texto, una llamada telefónica,etc.

2.5. METADATOS EN LA ESTRUCTURA DE LOS FRAGMENTOS DE UNA ESGLa ESG es un fichero de vital importancia en las comunicaciones DVB-H, sin el cuál

los terminales móviles no sabrían como encontrar la información que va en el aire en forma de señal DVB-H, ni como interpretarla. De ahí que el uso de los metadatos, para forma estos ficheros tan especiales, en la iniciativa DVB-H se considere como una de las partes fundamentales del proyecto de llevar la radiodifusión televisiva con contenidos enriquecidos e interactividad a los terminales móviles.

Vamos a pasar a explicar de qué metadatos se componen cada uno de los fragmentos que forman una ESG, para posteriormente y a modo de último ejemplo, mostrar como sería una una ESG propiamente dicha. Debemos hacer entender, que cada uno de los fragmentos son

156

metadatos definidos por el estándar DVB-IPDC, y que en su interior podemos encontrar nuevos metadatos definidos por este mismo estándar o por los estándares de metadatos TV-Anytime o MPEG-7, los cuales ya hemos comentado de manera más o menos exhaustiva en el capítulo anterior.

2.5.1. METADATOS EN EL FRAGMENTO SERVICE

Lo primero que vamos a aclarar es que los fragmentos Service no aparecen sueltos como tal en una ESG , sino que lo hacen formando parte de un metadato conocido como ServiceTable, y que agrupará a diferentes fragmentos Service. Esta estructura, o forma de proceder, se repetirá para cada uno de los tipos de fragmentos, de manera que en la ESG encontraremos, ContentTable, ScheduleEventTable,etc.

Figura 82. Modelo del metadato ServiceType.

El fragmento Service lo define el estándar DVB-IPDC, como un metadato de tipo complejo que tiene la estructura semántica mostrada en la figura 82, y que pasamos ahora a comentar en la tabla 14:

157

TIPO DE METADATO SEMÁNTICAServiceName Metadato del estándar TVA. Indica el nombre con el que se describe un servicio. El

servicio en la mayoría de los casos podemos equipararlo a un canal de televisión o de radio, ya que serán servicios de esos tipos.

ServiceNumber Metadato básico XML de tipo unsignedShort. Especifica un número identificador del servicio en la ESG.Este número puede ser mostrado al usuario como nombre del servicio, de manera que el usuario marcando en el teclado del terminal móvil dicho número pueda acceder al servicio asociado.

ServiceLogo Metadato MEPEG-7. Contiene una referencia a una representación multimedia de un servicio,bien sea una imagen o un clip de vídeo o audio.

ServiceDescription Metadato TVA. Contiene una descripción textual del servicio, indicando el lenguaje en el que se ha realizado la descripción.

ServiceGenre Metadato del estándar TV-Anytime. Especifica el género del contenido multimedia principal que se está ofreciendo a través del servicio.

ServiceType Metadato TVA. Especifica el tipo de servicio DVB-H que se está ofreciendo. En DVB-H distinguimos distintos tipos de servicios, como son: de radio, de televisión, de descarga de archivos, etc.

ParentalGuidance Metadato del estándar MPEG-7. Especifica el rango de edad para quién va dirigido el servicio.

ServiceLanguage Metadato básico XML. Especifica la lengua hablada usada en los contenidos que se están radiodifundiendo en el servicio.

ServicioProvider Metadato IPDC que distingue el proveedor de la ESG.

AcquisitionRef Metadato IPDC que contiene una referencia al fragmento Acquisition donde se encuentra la información necesaria (fichero.sdp) para que el terminal móvil pueda adquirir el servicio.

RelatedMaterial Metadato IPDC. Dentro contiene la información necesaria para el que el terminal pueda conocer un material relacionado al servicio; dónde, cuándo y cómo adquirirlo.

PrivateData Metadato IPDC. De uso privado por la plataforma.

Service Metadato IPDC. Metadato que contiene el resto de metadatos, representa al fragmento en si, posee tres atributos:

● serviceID. Algún tipo de URI que identifica al servicio.● freeToAir. Boleano que dice si es o no gratis el servicio.está o no codificado el

servicio.● clearToAir. Boleano.

Tabla 14. Metadatos del fragmento Service.

2.5.2. METADATOS EN EL FRAGMENTO SERVICEBUNDLE

Este caso nos centramos en el fragmento ServiceBundle, donde veremos al igual que antes su estructura semántica y una breve descripción de los metadatos que la componen.

158

Figura 83. Modelo del metadato ServiceBundleType.

Pasamos a dar una breve explicación de cada uno de los metadatos que componen un ServiceBundle en la siguiente tabla:

TIPO DE METADATOS SEMÁNTICAServiceBundleName Metadato del estándar MPEG-7. Nombre que especifica un Bundle o conjunto de

servicios.

ServiceBundleProvider Metadato IPDC. Especifica el proveedor del conjunto de servicios.

ServiceBundleMediaTitle Metadato del estándar MPEG-7. Hace referencia a una representación multimedia del Bundle de servicios.

ServiceBundleDescription Especifica una descripción textual del Bundle de servicios.

ServiceBundleGenre Metadato TVA. Género de los servicios agrupados bajo un mismo Bundle.

ServiceRef Metadato IPDC. Referencia a los distintos servicios que componen el Bundle.

ParentalGuidance Metadato del estándar MPEG-7. Especifica el rango de edad para quién va dirigido el Bundle servicios.

RelatedMaterial Metadato IPDC. Dentro contiene la información necesaria para el que el terminal pueda conocer un material relacionado al Bundle de servicios; dónde, cuándo y cómo adquirirlo.

ServiceBundle Metadato IPDC. Metadato que contiene el resto de metadatos, representa al fragmento en si, posee un atributo:

● serviceBundleID. Identificador único del Bundle de servicios.Tabla 14. Metadatos del fragmento ServiceBundle.

159

2.5.3. METADATOS EN EL FRAGMENTO CONTENT

Sintaxis del fragmento Content:

Figura 84. Metadatos del fragmento Content.

Tabla de los metadatos que encontramos en el fragmento Content.

TIPO DE METADATO SEMÁNTICATitle Metadato del estándar MPEG-7. Especifica el título de un contenido.

MediaTitle Metadato del estándar MPEG-7. Representación multimedia de un contenido.

ServiceRef Metadato IPDC. Referencia al servicio por el cual se va a transmitir el contenido.

Synopsis Metadato TVA. Pequeña descripción textual del contenido.

Keyword Metadato TVA. Palabra clave que caracteriza un contenido.

Genre Metadato TVA. Género que caracteriza al contenido.

ContentType Metadato TVA. Especifica que tipo de contenido es el que se está transmitiendo, si es contenido de descarga, de streaming o una combinación de ambos.

ParentalGuidance Metadato del estándar MPEG-7. Especifica el rango de edad para quién va dirigido el contenido.

Language Metadato MPEG-7. Describe el idioma hablado del contenido.

CaptionLanguage Metadato del estándar TV-Anytime. Especifica el idioma que se usa para anunciar el contenido al usuario.

SignLanguage Metadato TVA. Metadato equivalente al anterior.

CreditList Metadato TVA. Este metadato contiene una lista con los créditos del contenido. Si por ejemplo es una película nos indica los actores, director, guionista,etc.

160

TIPO DE METADATO SEMÁNTICARelatedMaterial Metadato IPDC. Dentro contiene la información necesaria para el que el terminal pueda

conocer un material relacionado al contenido; dónde, cuándo y cómo adquirirlo.

Duration Metadato básico de XML. Duración del contenido.

PrivatedData Metadato IPDC.

Content Metadato IPDC. Metadato que contiene el resto de metadatos, representa al fragmento en si, posee un atributo:

● contentID. Identificador único del Content.Tabla 15. Metadatos del fragmento Content.

2.5.4. METADATOS EN EL FRAGMENTO SCHEDULE-EVENT

Sintaxis del fragmento ScheduleEvent:

Figura 85. Metadatos del fragmento ScheduleEvent.

Los elementos que componen este fragmentos se describen en la siguiente tabla:

TIPO DE METADATO SEMÁNTICAPublishedStartTime Metadato básico XML del tipo dateTime. Es un metadato que se sirve para mostrar al

usuario la hora y la fecha en la que puede comenzar a consumir un contenido.

PublishedEndTime Metadato básico XML del tipo dateTime. Es un metadato que se sirve para mostrar al usuario la hora y la fecha en la que un contenido deja de estar disponible.

ServiceRef Hace referencia a que servicio está asociado dicho fragmento ScheduleEvent.

ScheduleEvent Metadato IPDC. Metadato que contiene el resto de metadatos, representa al fragmento en si, posee cinco atributos:

● live. Indica si el contenido es en directo.● repeat.● freeToAir.● clearToAir.● schduleID. Identifica al fragmento dentro de la ESG.

Tabla 16. Metadatos del fragmento ScheduleEvent.

161

2.5.5. METADATOS EN EL FRAGMENTO ACQUISITION

Sintaxis del fragmento Acquisition:

Figura 86. Metadatos del fragmento Acquisition.

Tabla de metadatos que aparecen en el fragmento Adquisition.

TIPO DE METADATO SEMÁNTICAComponentDescription Metadato del estándar IPDC. Describe los componentes de un servicio respecto a las

características del mismo y a las características de la sesión en la que están activos.

ZappingSuport Metadato del estándar IPDC. Indica si un servicio tiene disponible el zapping y que tipo está disponible.

KeyStream Metadato del estándar IPDC. Palabra clave para distinguir un Acquisition Fragment dentro de un flujo.

Acquisition Metadato IPDC. Metadato que contiene el resto de metadatos, representa al fragmento en si, posee dos atributos:

● acquisitionID. Identificador del fragmento dentro de una ESG.● ContentMimeType. Indica el tipo de contenido para que el terminal que

aplicación utilizar para consumir el servicio.

Tabla 17. Metadatos del fragmento Acquisition.

162

2.5.5. METADATOS EN EL FRAGMENTO PURCHASE

Sintaxis del fragmento Purchase:

Figura 87. Metadatos del fragmento Purchase.

Metadatos que aparecen en el fragmento Purchase:

TIPO DE METADATO SEMÁNTICAName Metadato MPEG-7.

Description Metadato MPEG-7.

MediaTitle Metadato MPEG-7.

PortalURL Metadato básico XML del tipo anyURI. Referencia al sitio web donde se encuentra el canal de compra.

ContactInfo Metadato básico XML del tipo anyURI. Información de contacto del operador del canal de compra.

PrivateData Metadato IPDC.

Purchase Metadato IPDC. Metadato que contiene el resto de metadatos, representa al fragmento en si, posee un atributo:

● purchaseChanenelID. Identificador único del canal del Purchase.

Tabla 18. Metadatos del fragmento Purchase.

2.5.6. EJEMPLO DE UNA ESG

A lo largo de los puntos anteriores hemos mostrado que elementos componen una ESG, y que metadatos componen a su vez dichos elementos o fragmentos. Sin embargo no hemos visto todavía que apariencia tiene un fichero ESG. Es por ello que para hacernos una idea más clara de aquello que hemos explicado anteriormente, mostramos a continuación la apariencia de una ESG que se transmite a un terminal DVB-H.

163

Figura 88. Modelo XML de una ESG.

164

6. CONCLUSIONESTras la lectura de este proyecto, se pretende que el lector asimile una serie de

conceptos e ideas que le permitan abrir su mente a una nueva forma de concebir soluciones. Una forma basada en el uso de los elementos denominados como metadatos. Es sobre este tipo de soluciones y sobre estos elementos, donde encontramos las obtenemos conclusiones.

Como se ha podido observar, el proyecto se estructura en tres capítulos bien diferenciados. El objetivo de esta estructuración, era el de conseguir que cada capítulo ofreciera al lector un conjunto de conclusiones que le permitiera introducirse, en el mundo de los metadatos, con una base lo suficientemente asentada.

Con esta premisa, lo primero que se pretende en el primer capítulo del proyecto, y creemos que se ha dado justo cumplimiento, es que el lector afiance su concepto sobre los metadatos. Muchas de las personas a las cuales este proyecto va dirigido, ya conocían, aunque fuera de oídas, a los metadatos. Sin embargo, a lo largo de este documento se ha dado una idea clara y concisa de qué son, cómo se estructuran y para qué se pueden utilizar.

Para ello en el capítulo primero del proyecto introducimos al lector en el mundo de los metadatos, ofreciéndole la definición más extendida de los metadatos, las clasificaciones más utilizadas y aceptadas; Bearman & Schats, clasificación de la Universidad de Cornell (estructurales, descriptivos y administrativos). Continuando con la lectura, creemos que en el apartado sobre las distintos contextos de aplicación de los metadatos se obtiene una idea básica, qué es uno de los ejes del proyecto:

“Los metadatos pueden usarse en multitud de campos o áreas y para infinidad de aplicaciones”.

Es fundamental que el lector se lleve esta idea bien asentada en su cabeza, pues una de las conclusiones que se pretende difundir, es que la limitación a la hora de usar los metadatos viene marcada por la tecnología, en ningún caso por el concepto de metadatos. De esta forma, habrá soluciones y aplicaciones que se terminarán encontrando e implementado, conforme la tecnología asociada a los metadatos avance, gracias a la aportación de los usuarios.

En el comienzo del capítulo dos, el lector se ha encontrado con dos de los conceptos más importantes de todo el proyecto, “la estandarización” y “la interoperabilidad” . A partir de ambos conceptos, el debe obtener dos conclusiones básicas.

●Para que los metadatos puedan expandirse, y la comunidad especializada los acepte como una solución, es necesario que se estandaricen. De esta forma nos aseguramos que todos utilizaremos las herramientas adecuadas, y que la heterogeneidad de formatos, tipos, clases, etc. se convertirá en un freno a la utilización de los metadatos.

●Puesto que hoy por hoy, es inviable la utilización de un estándar de metadatos universal, bajo mi opinión no sólo inviable sino que no sería útil, se hace necesaria la interoperabilidad entre distintos estándares. Para ello debemos recurrir a los schemas de metadatos, y a los distintas técnicas que se utilizan ( crosswalks, perfiles de aplicación, etc.).

Se ha mostrado una gama relativamente amplia de estándares de metadatos. Hemos analizado para que se utilizan dichos estándares, cuáles son los modelos de datos

165

en los que se basan, algunos de los metadatos más importantes que se utilizan en cada uno de ellos, e incluso hemos visto ejemplos de usos de los mismos mostrando los trozos de códigos donde aparecen. Con este planteamiento se ha conseguido mostrar una parte de la gran variedad de metadatos que existen, y como los estándares de metadatos se crean, en principio, para resolver una serie de problemas en un determinada área. Como por ejemplo:

●ID3 para la descripción de ficheros de audio, principalmente.

●Dublin Core para la descripción de todo tipo recursos y la rápida de recuperación de información.

●LOM para la descripción de contenidos educativos digitalizados ( por Internet).

●RDF para la descripción de recursos Web.

●MPEG-7 para la descripción de contenidos audiovisuales y multimedia.

●TV-Anytime para la gestión y control de contenidos audiovisuales y multimedia.

Como conclusión, de toda esta parte del capítulo, podemos decir que los metadatos, hoy por hoy, nos están siendo de gran utilidad para permitir que el hombre interactúe cada vez más con las máquinas, y ofreciendo a éstas las herramientas necesarias para hacer lo mismo con el hombre.

Para mostrar de una manera tangible estas últimas afirmaciones que hemos realizado, el tercer capítulo nos muestra un par de ejemplos reales. Estos ejemplos del uso de los metadatos no son más que dos, de las decenas, cientos o incluso miles de proyectos diferentes que se basan en el uso de los metadatos. Con estos ejemplos pretendemos mostrar como los metadatos se han convertido en uno de los motores que se usan en el campo de la investigación, el desarrollo y la innovación, cuando nos centramos en tecnologías digitales.

Puesto que vivimos en una era digital, y en la que cada vez, más áreas del conocimiento se apoyan en herramientas digitales, decir que los metadatos es una parte fundamental ellas, es decir que nuestra sociedad va a deber gran parte de sus próximos avances, a estas sencillas y a la vez complejas herramientas. Ésta es, en definitiva, la conclusión más importante, que yo humildemente, he sacado durante la elaboración de este proyecto, y que espero que algunos de los lectores del mismo acaben compartiendo conmigo.

166

7. BIBLIOGRAFÍA

➢http://es.wikipedia.org/wiki/Metadato

➢CAPLAN, Priscilla. Metadata Fundamentals for All Librarians. Chicago: ALA, 2003.

➢Cornell Universiti Library. Metadata Working Group: http://metadata-

wg.mannlib.cornell.edu/bibliography .

➢DCMI Bibliography: http://dublincore.org/documents/usageguide/bibliography.shtml .

➢GILLILAND-SWETLAND, Anne. Metadata, Where are We Going?. En: International Yearbook of

Library and Information Management 2003/2004: Metadata Applications and Management. G. E.

Gorman, ed. Lanham.

➢HUNTER, Philip and Marieke Guy. Metadata for harvesting: the Open Archives Initiative, and

How to Find Things on the Web. The Electronic Library, 2004.

➢MÉNDEZ RODRÍGUEZ, Eva María. Metadatos y Recuperación de información: estándares,

problemas y aplicabilidad en Bibliotecas Digitales .

➢Fuente oficial de información sobre ID3: http://www.id3.org/

➢Fuente oficial sobre Dublin Core: http://www.dublincore.org/

➢Dublin Core Metadata Elements Set : Reference Description.

http://purl.org/DC/about/elements_set.htm

➢Dublin Core Metadata Template: http ://www.lub.lu.se/cgi-bin/nmdc.pl

➢Dublin Core Qualifiers: http ://www.roads.lut.ac.uk/Metadata/DC-SubElements.html

➢IEEE Learning Object Metadata (LOM). Institute of Electrical and Electronics Engineers:

167

http://ltsc.ieee.org .

➢eLearning Workshops. Enebral, J. Dieciocho años del e-learning en España (2004):

http://www.elearningworkshops.com.

➢CODING OF MOVING PICTURES AND AUDIO: international organisation for Standardization

Organization International of Normalization iso/iec jtc1/sc29/wg11

➢Mpeg-7 description definition language (DDL): http://archive.dstc.edu.au/mpeg7-ddl/

➢Introduction to Mpeg-7 (v3.0):

http://ipsi.fhg.de/delite/Projects/MPEG7/Documents/W4325%20M7%20Intro.htm .

➢Specification Series: S-3 On: Metadata (Normative) Part A: Metadata Schemas. Document:

SP003v13 Part A Final Specification, Version 1.3 Date: February 5, 2003

➢Specification Series: S-3 On: Metadata (Normative) Part B: System Aspects in a Unidirectional

Environment. Document: SP003v13 Part B Final Specification, Version 1.3 Date: December 15,

2002 .

➢EVAIN,Jean-Pierre. European Broadcasting Union. Phase 1 TV-Anytime a decisive milestone in

open standards for Personal Video Recorders.

168

➢Antoniou, G.; Van Harmelen, F. 2004. A semantic web primer. Cambridge: MIT.

➢Berners-Lee, T.; Hendler, J.; Lassila, O. 2001. “The Semantic Web”. Scientific American, May

2001 (Accesible en formato html en la web de Scientific American: www.scientificamerican.com )

➢Berners-Lee, T. Semantic Web Architecture. Accesible en: http://www.w3.org/2000/Talks/1206-

xml2k-tbl/slide11-0.html

➢Copeland, J. 1996. Inteligencia artificial: una introducción filosófica. Madrid: Alianza, 1996.

➢ETSI TR 102 469 V1.1.1 (2006-05). “Digital Video Broadcasting (DVB); IP Datacast over DVB-H:

Architecture”. Conceptos sobre el funcionamiento de sistemas DVB-H.

➢ETSI TR 102 473 V1.1.1 (2006-04). “Digital Video Broadcasting (DVB); IP Datacast

over DVB-H: Use Cases and Services”. Punto 5 : Ejemplos de Servicios”.

➢ETSI TS 102 592 V1.1.1 (2007-10). “Digital Video Broadcasting (DVB); IPDC over

DVB-H:Electronic Service Guide (ESG) Implementation Guidelines”. Punto 6: Ejemplos de

escenarios.

➢Documento DVB-H. V1.0.0. Guadaltel.

➢Documento DVB-H V1.0.1. Guadaltel. Punto 8: Generación de Servivios.

169