¿Qué es un conjunto de datos?

A Chema, que sabe

¿Qué es un conjunto de datos? A veces definir y explicar los conceptos que parecen más elementales y obvios resulta difícil, porque nunca nos lo planteamos. Hace poco alguien nos peguntó qué es un Conjunto de Datos Espaciales (CDE), un concepto básico en la Directiva INSPIRE, y a los presentes nos costó más de lo que parece construir una explicación clara y coherente.

Obviamos el adjetivo espaciales, que en INSPIRE ha sustituido al geográfico de las normas ISO 19100 que nos parece más apropiado, a menos que se quieran incluir las representaciones digitales del Sistema Solar, la Vía Láctea, nuestro cúmulo de galaxias y ¿por qué no? las representaciones digitales tridimensionales de moléculas complejas como el ADN.

La traducción oficial de la Directiva dice que un conjunto de datos es una recopilación identificable de datos. Entonces ¿qué sentido tiene? ¿qué significa eso realmente? 

Pues en realidad es un grupo de datos que en un momento determinado se va a gestionar como un todo, como una unidad. Por ejemplo la hidrografía de un país, un nomenclátor geográfico o una cobertura LiDAR. Pero, aparte de operaciones particulares y muy concretas, como que un usuario nos pida unos datos, el resultado de un análisis o algo así ¿qué conjuntos de datos interesa considerar en una organización?

Por ejemplo ¿un fichero que describe solo un lago debe ser considerado un conjunto de datos (CD)? Pues depende. Las preguntas oportunas son ¿lo voy a gestionar como un todo? ¿voy a generar metadatos de él? ¿lo voy a procesar (capturar, editar, actualizar, publicar, etc.) individualmente? Si la respuesta es no, porque en realidad va a formar parte de la Hidrografía de la región o del país, no conviene considerarlo un CD. Por el contrario, si es un lago singular, como el lago Balatón de Polonia, el más grande de ese país, acompañado de multitud de sondeos y datos de composición y calidad de sus aguas, a lo mejor sí tiene sentido. 

La cuestión no es tan trivial como parece a primera vista y tiene que ver con la atomización de datos y servicios en la implementación de la Directiva INSPIRE. Parece que no tiene mucho sentido definir un conjunto de datos por cada tipo de objeto geográfico (feature type), porque complica mucho la gestión, hay que producir muchos metadatos y al fin y al cabo es algo arificial, porque de hecho esos datos no se gestionan por separado. Parece que para optimizar procesos lo mejor es definir CD lo más amplios posible, no atomizarlos y tener un único CD formado por todos los datos que produce una misma organización dentro de un tema INSPIRE, pensando en que tienen que ser conformes con unas mismas especificaciones.

Eso parece lo mejor salvo que haya dos procesos de producción muy diferentes y heterogéneos, con distintos métodos de producción, frecuencia de actualización, calidad de resultados, controles de calidad, etc. o que la demanda de los usuarios esté muy repartida y haya dos grupos de usuarios muy diferentes, con necesidades muy distintas, que utilizan, por ejemplo unos la red de ferrocarril y otros la red de carreteras, dentro del tema de Redes de Transporte (RT), con necesidades muy diferentes. En ese caso a lo mejor interesa definir dos CD.

La atomización también amenaza a los servicios y quizás no sea muy práctico tampoco definir un WMS (o un WMTS) diferente por cada feature type. Es algo que complica mucho la gestión y no parece que tenga muchas ventajas, salvo la de aumentar las estadísticas de CD y servicios implementados. O dicho de otra manera, hacer poco comparables los índices del seguimiento INSPIRE de países diferentes es otro de los inconvenientes de la atomización de CD. Así que parece buena idea, salvo que haya una razón de peso en contra, implementar un servicio de visualización por cada tema INSPIRE dentro de una organización.

Eso plantea otra cuestión y es que el marco INSPIRE, al hacer tanto énfasis en el tema, ha roto el mapa topográfico y ahora no hay ninguna garantía en el modelo de consistencia entre temas. Antes, la hidrografía, el relieve, las redes de transporte, las poblaciones, etc. coincidían cuando tenían que coincidir y encajaban perfectamente, al menos en teoría y si no era así, había un error. En INSPIRE no hay ningún ítem de metadatos, ningún elemento de calidad que permita decir, por ejemplo, que la geometría de una hidrografía es consistente con una descripción del relieve. (La consistencia entre CD es otro argumento para dividirlos lo menos posible).

Queda para los cartógrafos la tarea de ver cómo solucionar el problema (que INSPIRE no separe lo queha unido el cartógrafo); lo más cómodo es mantener procesos de captura y tratamiento de datos comunes hasta cierto momento  para garantizar esa consistencia, pero no siempre es posible y sería quizás conveniente pensar en procedimientos posteriores de ajuste automático, para eso tenemos el prometedor machine learning.

Publicado por el editor.