Las ciudades, las infraestructuras y el medio ambiente generan hoy un flujo constante de datos procedentes de sensores, redes de transporte, estaciones meteorológicas y plataformas de Internet of Things (IoT), entendidas como redes de dispositivos físicos (semáforos digitales, sensores de calidad de aire, etc.) capaces de medir y transmitir información a través de sistemas digitales. Este volumen creciente de información permite mejorar la prestación de servicios públicos, anticipar emergencias, planificar el territorio y responder a retos asociados al clima, la movilidad o la gestión de recursos. 

El incremento de fuentes conectadas ha transformado la naturaleza del dato geoespacial. Frente a los conjuntos tradicionales —actualizados de forma periódica y orientados a cartografía de referencia o inventarios administrativos— los datos dinámicos incorporan la dimensión temporal como componente estructural. Una observación de calidad del aire, un nivel de ocupación de tráfico o una medición hidrológica no solo describen un fenómeno, sino que lo sitúan en un momento concreto. La combinación espacio-tiempo convierte a estas observaciones en elementos fundamentales para sistemas operativos, modelos predictivos y análisis basados en series temporales. 

En el ámbito de los datos abiertos, este tipo de información plantea tanto oportunidades como requerimientos específicos. Entre las oportunidades se encuentran la posibilidad de construir servicios digitales reutilizables, de facilitar la supervisión en tiempo casi real de fenómenos urbanos y ambientales, y de fomentar un ecosistema de reutilización basado en flujos continuos de datos interoperables. La disponibilidad de datos actualizados incrementa además la capacidad de evaluación y auditoría de políticas públicas, al permitir contrastar decisiones con observaciones recientes. 

No obstante, la apertura de datos geoespaciales en tiempo real exige resolver problemas derivados de la heterogeneidad tecnológica. Las redes de sensores utilizan protocolos, modelos de datos y formatos diferentes; las fuentes generan volúmenes elevados de observaciones con alta frecuencia; y la ausencia de estructuras semánticas comunes dificulta el cruce de datos entre dominios como movilidad, medio ambiente, energía o hidrología. Para que estos datos puedan publicarse y reutilizarse de manera consistente, es necesario un marco de interoperabilidad que normalice la descripción de los fenómenos observados, la estructura de las series temporales y las interfaces de acceso. 

Los estándares abiertos del Open Geospatial Consortium (OGC) proporcionan ese marco. Definen cómo representar observaciones, entidades dinámicas, coberturas multitemporales o sistemas de sensores; establecen API basadas en principios web que facilitan la consulta de datos abiertos; y permiten que plataformas distintas intercambien información sin necesidad de integraciones específicas. Su adopción reduce la fragmentación tecnológica, mejora la coherencia entre fuentes y favorece la creación de servicios públicos basados en datos actualizados. 

Interoperabilidad: el requisito básico para abrir datos dinámicos 

Las administraciones públicas gestionan hoy datos generados por sensores de distinto tipo, plataformas heterogéneas, proveedores diferentes y sistemas que evolucionan de forma independiente. La publicación de datos geoespaciales en tiempo real exige una interoperabilidad que permita integrar, procesar y reutilizar información procedente de múltiples fuentes. Esta diversidad provoca inconsistencias en formatos, estructuras, vocabularios y protocolos, lo que dificulta la apertura del dato y su reutilización por terceros. Veamos qué aspectos de la interoperabilidad están afectados: 

• La interoperabilidad técnica: se refiere a la capacidad de los sistemas para intercambiar datos mediante interfaces, formatos y modelos compatibles. En los datos en tiempo real, este intercambio requiere mecanismos que permitan consultas rápidas, actualizaciones frecuentes y estructuras de datos estables. Sin estos elementos, cada flujo dependería de integraciones ad hoc, aumentando la complejidad y reduciendo la capacidad de reutilización. 

• La interoperabilidad semántica: los datos dinámicos describen fenómenos que cambian en periodos cortos —niveles de tráfico, parámetros meteorológicos, caudales, emisiones atmosféricas— y deben interpretarse de forma coherente. Esto implica contar con modelos de observación, vocabularios y definiciones comunes que permitan a aplicaciones distintas entender el significado de cada medición y sus unidades, condiciones de captura o restricciones. Sin esta capa semántica, la apertura de datos en tiempo real genera ambigüedad y limita su integración con datos procedentes de otros dominios. 

• La interoperabilidad estructural: los flujos de datos en tiempo real tienden a ser continuos y voluminosos, lo que hace necesario representarlos como series temporales o conjuntos de observaciones con atributos consistentes. La ausencia de estructuras normalizadas complica la publicación de datos completos, fragmenta la información e impide consultas eficientes. Para proporcionar acceso abierto a estos datos, es necesario adoptar modelos que representen adecuadamente la relación entre fenómeno observado, momento de la observación, geometría asociada y condiciones de medición. 

• La interoperabilidad en el acceso vía API: constituye una condición esencial para los datos abiertos. Las API deben ser estables, documentadas y basadas en especificaciones públicas que permitan consultas reproducibles. En el caso de datos dinámicos, esta capa garantiza que los flujos puedan ser consumidos por aplicaciones externas, plataformas de análisis, herramientas cartográficas o sistemas de monitorización que operan en contextos distintos al que genera el dato. Sin API interoperables, el dato en tiempo real queda limitado a usos internos. 

En conjunto, estos niveles de interoperabilidad determinan si los datos geoespaciales dinámicos pueden publicarse como datos abiertos sin generar barreras técnicas. 

Estándares OGC para publicar datos geoespaciales en tiempo real 

La publicación de datos georreferenciados en tiempo real requiere mecanismos que permitan que cualquier usuario —administración, empresa, ciudadanía o comunidad investigadora— pueda acceder a ellos de forma sencilla, con formatos abiertos y a través de interfaces estables. El Open Geospatial Consortium (OGC) desarrolla un conjunto de estándares que permiten exactamente esto: describir, organizar y exponer datos espaciales de forma interoperable y accesible, que contribuyan a la apertura de datos dinámicos. 

Qué es OGC y por qué sus estándares son relevantes 

El OGC es una organización internacional que define reglas comunes para que distintos sistemas puedan entender, intercambiar y usar datos geoespaciales sin depender de tecnologías concretas. Estas reglas se publican como estándares abiertos, lo que significa que cualquier persona o institución puede utilizarlos. En el ámbito de los datos en tiempo real, estos estándares permiten: 

• Representar lo que un sensor mide (por ejemplo, temperatura o tráfico).
• Indicar dónde y cuándo se hizo la observación.
• Estructurar series temporales.
• Exponer datos a través de API abiertas.
• Conectar dispositivos y redes IoT con plataformas públicas. 

En conjunto, este ecosistema de estándares permite que los datos geoespaciales —incluyendo los generados en tiempo real— puedan publicarse y reutilizarse siguiendo un marco coherente. Cada estándar cubre una parte específica del ciclo del dato: desde la definición de las observaciones y los sensores, hasta la forma en la que se exponen los datos mediante API abiertas o servicios web. Esta organización modular facilita que administraciones y organizaciones seleccionen los componentes que necesitan, evitando dependencias tecnológicas y garantizando que los datos puedan integrarse entre plataformas distintas. 

La familia OGC API: API modernas para acceder a datos abiertos 

Dentro de OGC, la línea más reciente es la familia OGC API, un conjunto de interfaces web modernas diseñadas para facilitar el acceso a datos geoespaciales mediante URL y formatos como JSON o GeoJSON, habituales en el ecosistema de datos abiertos. 

Estas API permiten: 

• Obtener solo la parte del dato que interesa.
• Realizar búsquedas espaciales (“dame solo lo que está en esta zona”).
• Acceder a datos actualizados sin necesidad de software especializado.
• Integrarlos fácilmente en aplicaciones web o móviles. 

En este informe: “Cómo utilizar las OGC API para potenciar la interoperabilidad de los datos geoespaciales”, ya te hablamos de algunas las API más populares del OGP. Mientras que el informe se centra en cómo utilizar las OGC API para la interoperabilidad práctica, este post amplía el foco explicando los modelos de datos subyacentes del OGC —como O&M, SensorML o Moving Features— que sustentan esa interoperabilidad. 

A partir de esta base, este post pone el foco en los estándares que hacen posible ese intercambio fluido de información, especialmente en contextos de datos abiertos y en tiempo real. Los estándares más importantes en el contexto de datos abiertos en tiempo real son: 

Tabla 1. Estándares OGC relevantes para datos geoespaciales en tiempo real

Modelos que estructuran observaciones y datos dinámicos 

Además de las API, OGC define varios modelos conceptuales de datos que permiten describir de forma coherente observaciones, sensores y fenómenos que cambian en el tiempo: 

• O&M (Observations & Measurements): modelo que define los elementos esenciales de una observación —fenómeno medido, instante, unidad y resultado— y que sirve como base semántica para datos de sensores y series temporales.
• SensorML: lenguaje que describe las características técnicas y operativas de un sensor, incluyendo su ubicación, calibración y proceso de observación.
• Moving Features: modelo que permite representar objetos móviles mediante trayectorias espacio-temporales (como vehículos, embarcaciones o fauna). 

Estos modelos facilitan que diferentes fuentes de datos puedan interpretarse de forma uniforme y combinarse en análisis y aplicaciones. 

El valor de estos estándares para los datos abiertos 

El uso de los estándares OGC facilita la apertura de datos dinámicos porque: 

• Proporciona modelos comunes que reducen la heterogeneidad entre fuentes.
• Facilita la integración entre dominios (movilidad, clima, hidrología).
• Evita dependencias de tecnología propietaria.
• Permite que el dato sea reutilizado en análisis, aplicaciones o servicios públicos.
• Mejora la transparencia, al documentar sensores, métodos y frecuencias.
• Asegura que los datos pueden ser consumidos directamente por herramientas comunes. 

En conjunto, forman una infraestructura conceptual y técnica que permite publicar datos geoespaciales en tiempo real como datos abiertos, sin necesidad de desarrollar soluciones específicas para cada sistema. 

Casos de uso de datos geoespaciales abiertos en tiempo real 

Los datos georreferenciados en tiempo real ya se publican como datos abiertos en distintos ámbitos sectoriales. Estos ejemplos muestran cómo diferentes administraciones y organismos aplican estándares abiertos y API para poner a disposición del público datos dinámicos relacionados con movilidad, medio ambiente, hidrología y meteorología. 

A continuación, se presentan varios dominios donde las Administraciones Públicas ya publican datos geoespaciales dinámicos utilizando estándares OGC. 

Movilidad y transporte 

Los sistemas de movilidad generan datos de forma continua: disponibilidad de vehículos compartidos, posiciones en tiempo casi real, sensores de paso en carriles bici, aforos de tráfico o estados de intersecciones semaforizadas. Estas observaciones dependen de sensores distribuidos y requieren modelos de datos capaces de representar variaciones rápidas en el espacio y en el tiempo. 

Los estándares OGC desempeñan un papel central en este ámbito. En particular, OGC SensorThings API permite estructurar y publicar observaciones procedentes de sensores urbanos mediante un modelo uniforme –incluyendo dispositivos, mediciones, series temporales y relaciones entre ellos– accesible a través de una API abierta. Esto facilita que diferentes operadores y municipios publiquen datos de movilidad de forma interoperable, reduciendo la fragmentación entre plataformas. 

El uso de estándares OGC en movilidad no solo garantiza compatibilidad técnica, sino que posibilita que estos datos se puedan reutilizar junto con información ambiental, cartográfica o climática, generando análisis multitemáticos para planificación urbana, sostenibilidad o gestión operativa del transporte.  

Ejemplo: 

El servicio abierto de Toronto Bike Share, que publica en formato SensorThings API el estado de sus estaciones de bicicletas y la disponibilidad de vehículos. 

Aquí cada estación es un sensor y cada observación indica el número de bicicletas disponibles en un momento concreto. Este enfoque permite que analistas, desarrolladores o investigadores integren estos datos directamente en modelos de movilidad urbana, sistemas de predicción de demanda o paneles de control ciudadano sin necesidad de adaptaciones específicas. 

Calidad del aire, ruido y sensores urbanos 

Las redes de monitorización de calidad del aire, ruido o condiciones ambientales urbanas dependen de sensores automáticos que registran mediciones cada pocos minutos. Para que estos datos puedan integrarse en sistemas de análisis y publicarse como datos abiertos, es necesario disponer de modelos y API coherentes. 

En este contexto, los servicios basados en estándares OGC permiten publicar datos procedentes de estaciones fijas o sensores distribuidos de forma interoperable. Aunque muchas administraciones utilizan interfaces tradicionales como OGC WMS para servir estos datos, la estructura subyacente suele apoyarse en modelos de observaciones derivados de la familia Observations & Measurements (O&M), que define cómo representar un fenómeno medido, su unidad y el instante de observación. 

Ejemplo: 

El servicio Defra UK-AIR Sensor Observation Service proporciona acceso a datos de mediciones de calidad del aire en tiempo casi real desde estaciones in situ en Reino Unido. 

La combinación de O&M para la estructura del dato y API abiertas para su publicación facilita que estos sensores urbanos formen parte de ecosistemas más amplios que integran movilidad, meteorología o energía, permitiendo análisis urbanos avanzados o paneles ambientales en tiempo casi real. 

Ciclo del agua, hidrología y gestión del riesgo 

Los sistemas hidrológicos generan datos cruciales para la gestión del riesgo: niveles y caudales en ríos, precipitaciones, humedad del suelo o información de estaciones hidrometeorológicas. La interoperabilidad es especialmente importante en este dominio, ya que estos datos se combinan con modelos hidráulicos, predicción meteorológica y cartografía de zonas inundables. 

Para facilitar el acceso abierto a series temporales y observaciones hidrológicas, varios organismos utilizan OGC API – Environmental Data Retrieval (EDR), una API diseñada para recuperar datos ambientales mediante consultas sencillas en puntos, áreas o intervalos temporales. 

Ejemplo: 

El USGS (United States Geological Survey), que documenta el uso de OGC API – EDR para acceder a series de precipitación, temperatura o variables hidrológicas. 

Este caso muestra cómo EDR permite solicitar observaciones específicas por ubicación o fecha, devolviendo únicamente los valores necesarios para el análisis. Aunque los datos concretos de hidrología del USGS se sirven mediante su API propia, este caso demuestra cómo EDR encaja con la estructura de datos hidrometeorológicos y cómo se aplica en flujos operativos reales. 

El empleo de estándares OGC en este ámbito permite que los datos hidrológicos dinámicos se integren con zonas inundables, ortoimágenes o modelos climáticos, creando una base sólida para sistemas de alerta temprana, planificación hidráulica y evaluación del riesgo. 

Observación y predicción meteorológica 

La meteorología es uno de los dominios con mayor producción de datos dinámicos: estaciones automáticas, radares, modelos numéricos de predicción, observaciones satelitales y productos atmosféricos de alta frecuencia. Para publicar esta información como datos abiertos, la familia de OGC API se está convirtiendo en un elemento clave, especialmente mediante OGC API – EDR, que permite recuperar observaciones o predicciones en ubicaciones concretas y en distintos niveles temporales. 

Ejemplo: 

El servicio NOAA OGC API – EDR, que proporciona acceso a datos meteorológicos y variables atmosféricas del National Weather Service (Estados Unidos). 

Esta API permite consultar datos en puntos, áreas o trayectorias, facilitando la integración de observaciones meteorológicas en aplicaciones externas, modelos o servicios basados en datos abiertos. 

El uso de OGC API en meteorología permite que datos procedentes de sensores, modelos y satélites puedan consumirse mediante una interfaz unificada, facilitando su reutilización para pronósticos, análisis atmosféricos, sistemas de soporte a la decisión y aplicaciones climáticas. 

Buenas prácticas para publicar datos geoespaciales abiertos en tiempo real 

La publicación de datos geoespaciales dinámicos requiere adoptar prácticas que garanticen su accesibilidad, interoperabilidad y sostenibilidad. A diferencia de los datos estáticos, los flujos en tiempo real presentan requisitos adicionales relacionados con la calidad de las observaciones, la estabilidad de las API y la documentación del proceso de actualización. A continuación, se presentan algunas prácticas recomendadas para administraciones y organizaciones que gestionan este tipo de datos. 

• Formatos y API abiertas estables: el uso de estándares OGC —como OGC API, SensorThings API o EDR— facilita que los datos puedan consumirse desde múltiples herramientas sin necesidad de adaptaciones específicas. Las API deben ser estables en el tiempo, ofrecer versiones bien definidas y evitar dependencias de tecnologías propietarias. Para datos ráster o modelos dinámicos, los servicios OGC como WMS, WMTS o WCS siguen siendo adecuados para visualización y acceso programático. 

• Metadatos compatibles con DCAT-AP y modelos OGC: la interoperabilidad de catálogos requiere describir los conjuntos de datos utilizando perfiles como DCAT-AP, complementado con metadatos geoespaciales y de observación basados en O&M (Observations & Measurements) o SensorML. Estos metadatos deben documentar la naturaleza del sensor, la unidad de medida, la frecuencia de muestreo y posibles limitaciones del dato. 

• Políticas de calidad, frecuencia de actualización y trazabilidad: los datasets dinámicos deben indicar explícitamente su frecuencia de actualización, la procedencia de las observaciones, los mecanismos de validación aplicados y las condiciones bajo las cuales se generaron. La trazabilidad es esencial para que terceros puedan interpretar correctamente los datos, reproducir análisis e integrar observaciones procedentes de fuentes distintas. 

• Documentación, límites de uso y sostenibilidad del servicio: la documentación debe incluir ejemplos de uso, parámetros de consulta, estructura de respuesta y recomendaciones para gestionar el volumen de datos. Es importante establecer límites razonables de consulta para garantizar la estabilidad del servicio y asegurar que la administración puede mantener la API a largo plazo. 

• Aspectos de licencias para datos dinámicos: la licencia debe ser explícita y compatible con la reutilización, como CC BY 4.0 o CC0. Esto permite integrar datos dinámicos en servicios de terceros, aplicaciones móviles, modelos predictivos o servicios de interés público sin restricciones innecesarias. La consistencia en la licencia facilita también el cruce de datos procedentes de distintas fuentes. 

Estas prácticas permiten que los datos dinámicos se publiquen de forma fiable, accesible y útil para toda la comunidad reutilizadora. 

Los datos geoespaciales dinámicos se han convertido en una pieza estructural para comprender fenómenos urbanos, ambientales y climáticos. Su publicación mediante estándares abiertos permite que esta información pueda integrarse en servicios públicos, análisis técnicos y aplicaciones reutilizables sin necesidad de desarrollos adicionales. La convergencia entre modelos de observación, API OGC y buenas prácticas en metadatos y licencias ofrece un marco estable para que administraciones y reutilizadores trabajen con datos procedentes de sensores de forma fiable. Consolidar este enfoque permitirá avanzar hacia un ecosistema de datos públicos más coherente, conectado y preparado para usos cada vez más demandantes en movilidad, energía, gestión del riesgo y planificación territorial. 

El diseño de API web es una disciplina fundamental para el desarrollo de aplicaciones y servicios, al facilitar el intercambio fluido de datos entre diferentes sistemas. En el contexto de las plataformas de datos abiertos, las API cobran especial importancia, ya que permiten a los usuarios acceder de manera automática y eficiente a la información necesaria, ahorrando costes y recursos.

Este artículo explora los principios esenciales que deben guiar la creación de API web eficaces, seguras y sostenibles, en base a los principios recopilados por el Grupo de Arquitectura Técnica ligado a World Wide Web Consortium (W3C), siguiendo estándares éticos y técnicos. Aunque estos principios hacen referencia al diseño de API, muchos son aplicables al desarrollo web en general.

Se busca que los desarrolladores puedan garantizar que sus API no solo cumplan con los requisitos técnicos, sino que también respeten la privacidad y seguridad de los usuarios, promoviendo una web más segura y eficiente para todos.

En este post, analizaremos algunos consejos para los desarrolladores de las API y cómo se pueden poner en práctica.

Prioriza las necesidades del usuario

Al diseñar una API, es crucial seguir la jerarquía de necesidades establecida por el W3C:

• Primero, las necesidades del usuario final.
• Segundo, las necesidades de los desarrolladores web.
• Tercero, las necesidades de los implementadores de navegadores.
• Por último, la pureza teórica.

Así podremos impulsar una experiencia de usuario que sea intuitiva, funcional y atractiva. Esta jerarquía debe guiar las decisiones de diseño, aunque reconociendo que en ocasiones estos niveles se interrelacionan: por ejemplo, una API más fácil de usar para los desarrolladores suele resultar en mejor experiencia para el usuario final.

Garantiza la seguridad

Garantizar la seguridad al desarrollar una API es crucial para proteger, tanto los datos de los usuarios, como la integridad del sistema. Una API insegura puede ser un punto de entrada para atacantes que buscan acceder a información sensible o comprometer la funcionalidad del sistema. Por ello, al añadir nuevas funcionalidades, debemos cumplir las expectativas del usuario y garantizar su seguridad.

En este sentido, es esencial considerar factores relacionados con la autenticación de usuarios, encriptación de datos, validación de entradas, gestión de tasas de solicitud (o Rate Limiting, para limitar la cantidad de solicitudes que un usuario puede hacer en un periodo determinado y evitar ataques de denegación de servicio), etc. También es necesario monitorear continuamente las actividades de la API y mantener registros detallados para detectar y responder rápidamente a cualquier actividad sospechosa.

Desarrolla una interfaz de usuario que transmita confianza

Es necesario considerar cómo las nuevas funcionalidades impactan en las interfaces de usuario. Las interfaces deben ser diseñadas para que los usuarios puedan confiar y verificar que la información proporcionada es genuina y no ha sido falsificada. Aspectos como la barra de direcciones, los indicadores de seguridad y las solicitudes de permisos deben dejar claro con quién se están interactuando y cómo.

Por ejemplo, la función alert de JavaScript, que permite mostrar un cuadro de diálogo modal que parece parte del navegador, es un caso histórico que ilustra esta necesidad. Esta función, creada en los primeros días de la web, ha sido frecuentemente utilizada para engañar a usuarios haciéndoles creer que están interactuando con el navegador, cuando en realidad lo hacen con la página web. Si esta funcionalidad se propusiera hoy, probablemente no sería aceptada por estos riesgos de seguridad.

Pide consentimiento explicito a los usuarios

En el contexto de satisfacer una necesidad de usuario, una página web puede utilizar una función que suponga una amenaza. Por ejemplo, el acceso a la geolocalización del usuario puede ser de ayuda en algunos contextos (como una aplicación de mapas), pero también afecta a la privacidad.

En estos casos es necesario que el usuario consienta su uso. Para ello:

• El usuario debe entender a qué está accediendo. Si no puedes explicar a un usuario tipo a qué está consintiendo de forma inteligible, deberás reconsiderar el diseño de la función.
• El usuario debe poder elegir entre otorgar o rechazar ese permiso de manera efectiva. Si se rechaza una solicitud de permiso, la página web no podrá hacer nada que el usuario crea que ha descartado.

Al pedir consentimiento, podemos informar al usuario de qué capacidades tiene o no tiene la página web, reforzando su confianza en la seguridad del sitio. Sin embargo, el beneficio de una nueva función debe justificar la carga adicional que supone para el usuario decidir si otorga o no permiso para una función.

Usa mecanismos de identificación adecuados al contexto

Es necesario ser transparente y permitir a las personas controlar sus identificadores y la información adjunta a ellos que proporcionan en diferentes contextos en la web.

Las funcionalidades que utilizan o dependen de identificadores vinculados a datos sobre una persona conllevan riesgos de privacidad que pueden ir más allá de una sola API o sistema. Esto incluye datos generados pasivamente (como su comportamiento en la web) y aquellos recopilados activamente (por ejemplo, a través de un formulario). En este sentido, es necesario entender el contexto en el que se usarán y cómo se integrarán con otras funcionalidades de la web, asegurando de que el usuario pueda dar un consentimiento adecuado.

Es recomendable diseñar API que recopilen la mínima cantidad de datos necesarios y usar identificadores temporales de corta duración, a menos que sea absolutamente necesario un identificador persistente.

Crea funcionalidades compatibles con toda la gama de dispositivos y plataformas

En la medida de lo posible, asegura que las funcionalidades de la web estén operativas en diferentes dispositivos de entrada y salida, tamaños de pantalla, modos de interacción, plataformas y medios, favoreciendo la flexibilidad del usuario.

Por ejemplo, los modelos de diseño 'display: block', 'display: flex' y 'display: grid' en CSS, por defecto, colocan el contenido dentro del espacio disponible y sin solapamientos. De este modo funcionan en diferentes tamaños de pantalla y permiten a los usuarios elegir su propia fuente y tamaño sin causar desbordamiento de texto.

Agrega nuevas capacidades con cuidado

Añadir nuevas capacidades a la web requiere tener en consideración las funcionalidades y el contenido ya existentes, para valorar cómo va a ser su integración. No hay que asumir que un cambio es posible o imposible sin verificarlo primero.

Existen muchos puntos de extensión que permiten agregar funcionalidades, pero hay cambios que no se pueden realizar simplemente añadiendo o eliminando elementos, porque podrían generar errores o afectar a la experiencia de usuario. Por ello es necesario verificar antes la situación actual, como veremos en el siguiente apartado.

Antes de eliminar o cambiar funcionalidades, comprende su uso actual

Es posible eliminar o cambiar funciones y capacidades, pero primero hay que conocer bien la naturaleza y el alcance de su impacto en el contenido existente. Para ello puede ser necesario investigar cómo se utilizan las funciones actuales.

La obligación de comprender el uso existente se aplica a cualquier función de la que dependan los contenidos. Las funciones web no se definen únicamente en las especificaciones, sino también en la forma en que los usuarios las utilizan.

La práctica recomendada es priorizar la compatibilidad de las nuevas funciones con el contenido existente y el comportamiento del usuario. En ocasiones, una cantidad significativa de contenido puede depender de un comportamiento concreto. En estas situaciones, se desaconseja eliminar o cambiar dicho comportamiento.

Deja la web mejor de lo que la encontraste

La forma de añadir nuevas capacidades a una plataforma web es mejorando la plataforma en su conjunto, por ejemplo, sus características de seguridad, privacidad o accesibilidad.

La existencia de un defecto en una parte concreta de la plataforma no debe servir de excusa para añadir o ampliar funcionalidades adicionales con el fin de solucionarlo, ya que con ello se pueden duplicar problemas y disminuir la calidad general de la plataforma. Siempre que sea posible, hay que crear nuevas capacidades web que mejoren la calidad general de la plataforma, mitigando los defectos existentes de forma global.

Minimiza los datos del usuario

Hay que diseñar las funcionalidades para que sean operativas con la mínima cantidad necesaria de datos aportados por el usuario para llevar a cabo sus objetivos . Con ello, limitamos los riesgos de que se divulguen o utilicen indebidamente.

Se recomienda diseñar las API de forma que a los sitios web les resulte más fácil solicitar, recopilar y/o transmitir una pequeña cantidad de datos (datos más granulares o específicos), que trabajar con datos más genéricos o masivos. Las API deben proporcionar granularidad y controles de usuario, en particular si trabajan sobre datos personales.

Otras recomendaciones

El documento también ofrece consejos para el diseño de API utilizando diversos lenguajes de programación. En este sentido, proporciona recomendaciones ligadas a HTML, CSS, JavaScript, etc. Puedes leer las recomendaciones aquí.

Además, si estás pensando en integrar una API en tu plataforma de datos abiertos, te recomendamos la lectura de la Guía práctica para la publicación de Datos Abiertos usando APIs.

Siguiendo estas indicaciones podrás desarrollar sitios web consistentes y útiles para los usuarios, que les permitan alcanzar sus objetivos de manera ágil y optimizando recursos.

En un mundo donde la información geoespacial es crucial para abordar desafíos globales como el cambio climático y la gestión de recursos naturales, la interoperabilidad y la creación de estándares son esenciales. La interoperabilidad facilita la colaboración entre organizaciones, impulsa la innovación y asegura que los datos sean accesibles y utilizables por todos. El Open Geospatial Consortium (OGC) desempeña un papel vital en este contexto, desarrollando estándares abiertos que garantizan la compatibilidad y el intercambio eficiente de datos geoespaciales.

Uno de los estándares que ofrece OGC son una serie de API, que representan un avance significativo en la gestión y compartición de datos geoespaciales. Diseñadas para facilitar el acceso y uso de datos geográficos a través de la web, estas API utilizan tecnologías modernas como REST y JSON, lo que las hace compatibles con una amplia variedad de aplicaciones y plataformas. Además, las OGC API promueven la interoperabilidad, escalabilidad y seguridad, facilitando la integración y el análisis de datos geoespaciales en tiempo real.

Actualmente, el OGC está trabajando con la implementación de los estándares siguiendo el concepto de Building Blocks, que son componentes modulares diseñados para facilitar la creación y gestión de datos geoespaciales y servicios relacionados. Estos bloques proporcionan un marco estándar y reutilizable que permite integrar y operar eficientemente con datos de localización en diversas aplicaciones y sistemas. Entre sus ventajas se destacan la interoperabilidad, la reutilización, la eficiencia y la precisión en la gestión de datos geoespaciales.

En España, la implementación de las OGC API está avanzando con éxito en diversas instituciones y sectores. Organismos como el Centro Nacional de Información Geográfica con la publicación de los productos del Sistema Cartográfico Nacional, la IDE de Navarra y la IDE de Catalunya ya han adoptado  estos estándares para mejorar la gestión y accesibilidad de los datos geoespaciales. La integración de información espacial con otros tipos de datos, como los estadísticos, proporciona una visión más completa y útil para la toma de decisiones, mejorando significativamente la calidad y utilidad de las aplicaciones geoespaciales.

En resumen, los nuevos estándares y Building Blocks del OGC ofrecen numerosas ventajas que mejoran la eficiencia, interoperabilidad y calidad de las aplicaciones y servicios geoespaciales. Estos beneficios se extienden a desarrolladores, organizaciones y usuarios finales, promoviendo un ecosistema geoespacial más integrado y robusto. Al adoptar estos estándares, se asegura que las soluciones sean interoperables, reutilizables y accesibles a largo plazo, beneficiando a toda la comunidad geoespacial.

Este es el tema central del informe “Cómo utilizar OGC API para mejorar la interoperabilidad de los datos geoespaciales”, donde se explica cómo funcionan las OGC API, acercándonos también al concepto de los Building Blocks, con el objetivo de que el lector pueda implementar su uso en su organización. Puedes leer el informe completo aquí.

También tienes disponible un pódcast con la autora del informe, Mayte Toscano, que destaca lo más relevante:

Escucha el pódcast

Vídeo del pódcast

A continuación, se recoge la definición de diversos términos relacionados con los datos y tecnologías relacionadas.

1. Glosario de términos relacionados con datos abiertos.

¿Qué retos afrontan los publicadores de datos?

En la era digital actual, la información es un activo estratégico que impulsa la innovación, la transparencia y la colaboración en todos los sectores de la sociedad. Es por ello por lo que las iniciativas de publicación de datos han experimentado un enorme desarrollo como mecanismo fundamental para desbloquear el potencial de estos datos, permitiendo que gobiernos, organizaciones y ciudadanos accedan, utilicen y compartan.

No obstante, existen aún muchos retos tanto para publicadores de datos como para consumidores de los mismos. Aspectos como el mantenimiento de las APIs (Application Programming Interfaces) que nos permiten acceder y consumir los conjuntos de datos publicados o la correcta replicación y sincronización de conjuntos de datos cambiantes siguen siendo desafíos muy relevantes para estos actores.

En este post, exploraremos cómo los Linked Data Event Streams (LDES), un nuevo mecanismo de publicación de datos, pueden ayudarnos a solventar estos retos. ¿Qué es exactamente LDES? ¿Cómo difiere de las prácticas tradicionales de publicación de datos? Y, lo más importante, ¿cómo puede ayudar a publicadores y consumidores de datos a facilitar el uso de los conjuntos de datos disponibles?

Destilando los aspectos claves de LDES

Cuando desde la Universidad de Gante se comenzó a trabajar en un nuevo mecanismo para la publicación de datos abiertos, la pregunta a la que pretendían dar respuesta era: ¿Cuál es la mejor API posible que podemos diseñar para exponer conjuntos de datos abiertos?

En la actualidad, los organismos publicadores de datos recurren a múltiples mecanismos para publicar sus diferentes conjuntos de datos. Por un lado, es fácil encontrarnos APIs. Destacan las de tipo SPARQL, estándar para consulta de datos enlazados (Link Data), pero también de tipo REST o de tipo WFS, para el acceso a conjuntos de datos con componente geoespacial. Por otro lado, es muy común que encontremos la posibilidad de acceder a volcados de datos en diferentes formatos (i.e. CSV, JSON, XLS, etc.) que podamos descargar para su utilización.

En el caso de los volcados de datos, es muy fácil encontrarnos con problemas de sincronización. Esto ocurre cuando, tras un primer volcado, se produce un cambio que requiere la modificación del conjunto de datos original como, por ejemplo, el cambio del nombre de una calle en un callejero previamente descargado. Ante este cambio, si el tercero opta por modificar el nombre de la calle sobre el volcado inicial en lugar de esperar a que el publicador actualice sus datos en el repositorio maestro para realizar un nuevo volcado, los datos manejados por el tercero quedarán desincronizados frente a los manejados por el publicador. De igual forma, si es el publicador el que actualiza su repositorio maestro pero estos cambios no son descargados por el tercero, ambos manejarán diferentes versiones del conjunto de datos.

Por otra parte, si el publicador ofrece el acceso a los datos a través de APIs de consulta, en lugar de mediante volcados de los datos a los terceros, se solucionan los problemas de sincronización, pero la construcción y mantenimiento de un alto y variado volumen de las mismas supone un elevado esfuerzo a los publicadores de datos.

LDES busca solventar estas diferentes problemáticas aplicando el concepto de Linked Data a un event stream o flujo de datos. Según la definición que aparece en su propia especificación, un Linked Data Event Stream (LDES) es una colección de objetos inmutables donde cada objeto está descrito en ternas RDF.

En primer lugar, el hecho de que los LDES apuesten por Linked Data aporta principios de diseño que permiten combinar datos diversos y/o pertenecientes a diferentes fuentes, así como su consulta a través de mecanismos semánticos que permiten legibilidad tanto por humanos como por máquinas. En resumen, aporta interoperabilidad y consistencia entre conjuntos de datos, y facilita por tanto su búsqueda y descubrimiento.

Por otro lado, los event streams o flujos de datos, permiten a los consumidores replicar la historia de los conjuntos de datos, así como sincronizar los cambios recientes. Cualquier nuevo registro añadido a un conjunto de datos o cualquier modificación de los registros existentes (en definitiva, cualquier cambio), se registra como un nuevo evento incremental en el LDES que no alterará los eventos anteriores. Por tanto, pueden publicarse y consumirse datos como una secuencia de eventos, lo cual es útil para datos que cambian con frecuencia, como información en tiempo real o información que sufre actualizaciones constantes, ya que permite la sincronización de las últimas actualizaciones sin necesidad de hacer una nueva descarga completa de todo el repositorio maestro tras cada modificación.

En un modelo de este tipo, el editor solo necesitará desarrollar y mantener una API, el LDES, en lugar de múltiples APIs como WFS, REST o SPARQL. Los diferentes terceros que deseen utilizar los datos publicados se conectarán (cada tercero implementará su cliente LDES) y recibirán los eventos de los streams a los que se hayan suscrito. Cada tercero creará a partir de la información recabada las APIs específicas que considere oportunas en base al tipo de aplicaciones que quieran desarrollar o fomentar. En definitiva, el publicador no tendrá que resolver todas las potenciales necesidades que tenga cada tercero en la publicación de datos, sino que dando un interfaz LDES (API base mínima) cada tercero se centrará en su problemática.

Además, para facilitar el acceso en grandes volúmenes de datos o a datos que pueden estar distribuidos en diferentes fuentes, como un inventario de puntos de recarga eléctrica en Europa, LDES aporta la capacidad de fragmentación de los conjuntos de datos. A través de la especificación TREE (en inglés, árbol), LDES permite establecer diferentes tipos de relaciones entre fragmentos de datos. Esta especificación permite publicar colecciones de entidades, llamados miembros, y ofrece la capacidad de generar una o más representaciones de estas colecciones. Estas representaciones se organizan como vistas, distribuyendo los miembros a través de páginas o nodos interconectados mediante relaciones. Así, si deseamos que los datos se puedan consultar a través de índices temporales, se podrá establecer una fragmentación temporal y acceder solo a las páginas de un intervalo temporal. De igual forma, se podrán plantear índices alfabéticos o geoespaciales y así un consumidor podrá acceder sólo a aquellos datos necesarios sin la necesidad de realizar el “volcado” del conjunto de datos completo.

¿Qué conclusiones podemos extraer de LDES?

En este post hemos observado el potencial de LDES como mecanismo para la publicación de datos. Algunos de los aprendizajes más relevantes son:

• LDES persigue facilitar la publicación de datos a través de APIs base mínimas que sirvan como punto de conexión para cualquier tercero que desee consultar o construir aplicaciones y servicios sobre conjuntos de datos.
• La construcción de un servidor LDES, no obstante, tiene cierto nivel de complejidad técnica a la hora de establecer la arquitectura necesaria para el manejo de los flujos de datos publicados y su adecuada consulta por parte de consumidores de datos.
• El diseño de LDES permite la gestión tanto de datos con una elevada tasa de cambios  (i.e. datos provenientes de sensores), como datos con una baja tasa de cambios (i.e. datos provenientes de un callejero). Ambos escenarios pueden manejar cualquier modificación del conjunto de datos como un flujo de datos.
• LDES soluciona de forma eficiente la gestión de registros históricos, versiones y fragmentos de conjuntos de datos. Para ello se apoya en la especificación TREE pudiendo establecer diferentes tipos de fragmentación sobre el mismo conjunto de datos.

¿Te gustaría saber más?

Dejamos a continuación algunas referencias que han servido para redactar este post y pueden servir al lector que desee profundizar en el mundo de LDES:

• Linked Data Event Streams: the core API for publishing base registries and sensor data, Pieter Colpaert. ENDORSE, 2021. https://youtu.be/89UVTahjCvo?si=Yk_Lfs5zt2dxe6Ve&t=1085
• Webinar on LDES and Base registries. Interoperable Europe, 17 January 2023. https://www.youtube.com/watch?v=wOeISYms4F0&ab_channel=InteroperableEurope
• SEMIC Webinar on the LDES specification. Interoperable Europe, 21 April 2023. https://www.youtube.com/watch?v=jjIq63ZdDAI&ab_channel=InteroperableEurope
• Linked Data Event Streams (LDES). SEMIC Support Centre. https://joinup.ec.europa.eu/collection/semic-support-centre/linked-data-event-streams-ldes
• Publishing data with Linked Data Event Streams: why and how. EU Academy. https://academy.europa.eu/courses/publishing-data-with-linked-data-event-streams-why-and-how

Contenido elaborado por Juan Benavente, ingeniero superior industrial y experto en Tecnologías ligadas a la economía del dato. Los contenidos y los puntos de vista reflejados en esta publicación son responsabilidad exclusiva de su autor.

La Directiva INSPIRE (Infrastructure for Spatial Information in Europe) establece las reglas generales para el establecimiento de una Infraestructura de Información espacial en la Comunidad Europea basada en las Infraestructuras de los Estados miembro. Aprobada por el Parlamento Europeo y el Consejo el 14 de marzo de 2007 (Directiva 2007/2/CE), esta entró en vigor el 25 de abril de 2007.

INSPIRE permite encontrar, compartir y utilizar con más facilidad los datos espaciales de diferentes países. La información está disponible a través de un portal online  desde el que se pueden encontrar desglosados en distintos formatos y temáticas de interés.

Para asegurar que estos datos sean compatibles e interoperables en un contexto comunitario y transfronterizo, la Directiva exige que se adopten Normas de Ejecución comunes (Implementing Rules) específicas para las siguientes áreas:

• Metadatos
• Conjuntos de datos
• Servicios de red
• Uso compartido de datos y servicios
• Servicios de datos espaciales
• Monitoreo e informes

La implementación técnica de estas normas se realiza mediante las Guías Técnicas o Directrices (Technical Guidelines), documentos técnicos basados en estándares y normas internacionales.

Inspire e interoperabilidad semántica

Estas normas se consideran decisiones o reglamentos de la Comisión y, por lo tanto, son de obligado cumplimiento en cada uno de los países de la Unión. La transposición de esta Directiva al ordenamiento jurídico español se desarrolla a través de la Ley 14/2010 de 5 de julio, la cual hace referencia a las infraestructuras y los servicios de información geográfica de España (LISIGE) y el portal IDEE, ambos son el resultado de la implementación de la Directiva INSPIRE en España.

En INSPIRE juega un papel decisivo la interoperabilidad semántica. Gracias a esta, existe un lenguaje común en los datos espaciales, pues la integración del conocimiento solo es posible cuando se logra una homogenización o entendimiento común de los conceptos que constituyen un dominio o área de conocimiento. Así, en INSPIRE, la interoperabilidad semántica es la encargada de asegurar que el contenido de la información intercambiada sea entendido de la misma manera por cualquier sistema.

Por ello, en la implementación de los modelos de datos espaciales en INSPIRE, en formato de intercambio GML, podemos encontrar los codelist que son una parte importante de las especificaciones de datos de INSPIRE y contribuyen sustancialmente a la interoperabilidad.

En general, una codelist o lista de códigos contiene varios términos cuyas definiciones son universalmente aceptadas y comprendidas. Las listas de códigos favorecen la interoperabilidad de los datos y constituyen un vocabulario compartido por una comunidad. Incluso pueden ser multilingües.

Las listas de códigos INSPIRE se administran y mantienen comúnmente en Registro Inspire Central Federado (ROR) que proporciona capacidades de búsqueda, de modo que tanto los usuarios finales como las aplicaciones cliente pueden acceder fácilmente a los valores de la lista de códigos como referencia.

Los registros son necesarios porque:

• Proporcionan los códigos definidos en las Directrices Técnicas (Guidelines), Reglamentos y Especificaciones técnicas necesarios para implementar la Directiva
• Permiten referencias inequívocas de los elementos
• Proporcionna identificadores únicos y persistentes para los recursos
• Permiten una gestión y control de versiones coherentes de los diferentes elementos

Las listas de códigos utilizados en INSPIRE se mantienen en:

• El Registro Inspire Central Federado (ROR)
• El registro de listas de códigos de un estado miembro
• El registro de listas de un tercero externo reconocido que mantiene una lista de códigos específica de dominio.

Para agregar una nueva lista de códigos, tendrá que configurar su propio registro o trabajar con la administración de uno de los registros existentes para publicar su lista de códigos. Este puede ser un proceso bastante complicado pero una nueva herramienta nos ayuda en esta labor.

Re3gistry es una solución de código abierto reutilizable y publicado bajo licencia EUPL, que permite a las empresas y organizaciones administrar y compartir \"códigos de referencia\" a través de URI persistentes, asegurando que los conceptos se referencian inequívocamente en cualquier dominio y facilitando la gestión de estos recursos gráficamente durante todo su ciclo de vida.

Financiado por ELISE, ISA2 es una solución reconocida por los europeos en el Marco de interoperabilidad como una herramienta de apoyo.Ilustración 3 Imagen de la interface de Re3gister.

Ilustración 3: Imagen de la interface de Re3gister

Re3gistry está disponible tanto para Windows como para Linux y ofrece una Interfaz Web fácil de usar para agregar, editar y administrar los registros y códigos de referencia. Además, permite la gestión del ciclo de vida completo de los códigos de referencia (basado en la norma ISO 19135: 2005 Procedimientos integrados para el registro de códigos de referencia)

La interfaz de edición también proporciona un indicador para permitir que el sistema exponga el código de referencia en el formato que permite su integración con RoR, de esta manera, eventualmente se puede importar en la federación de registro INSPIRE. Para esta integración, Reg3gistry hace una exportación en un formato basado en las siguientes especificaciones:

• El vocabulario del Catálogo de datos del W3C (DCAT) que se utiliza para modelar el registro de entidades (dcat:Catalog).
• El Sistema de Organización Simple del Conocimiento (SKOS) del W3C que se utiliza para modelar el registro de entidades (skos:ConceptScheme) y el elemento (skos:Concept).

Otras características destacables de Re3gistry

• Modelos de datos altamente flexibles y personalizables
• Soporte de contenido en varios idiomas
• Soporte para el control de versiones
• API RESTful con negociación de contenido (incluido el descriptor OpenAPI 3)
• Búsqueda de texto-libre
• Formatos soportados: HTML, ISO 19135 XML, JSON
• Los formatos de servicio se pueden agregar o personalizar fácilmente (formatos predeterminados: JSON e ISO 19135 XML)
• Múltiples opciones de autentificación
• Elementos gobernados externamente a los que se hace referencia a través de URIs
• Soporte de formato de federación de registro INSPIRE (opción para crear automáticamente el formato RoR)
• Fácil exportación y reindexación de datos (SOLR)
• Guías para usuarios, administradores y desarrolladores
• Fuente RSS

En definitiva, Re3gistry  proporciona un punto de acceso central donde las etiquetas y descripciones de los códigos de referencia son fácilmente accesibles tanto para humanos como para máquinas, al tiempo que fomenta la interoperabilidad semántica entre organizaciones ya que permite:

• Evitar errores comunes como faltas de ortografía, ingresar sinónimos o completar formularios en línea.
• Facilitar la internacionalización de las interfaces de usuario proporcionando etiquetas multilingües.
• Garantizar la interoperabilidad semántica en el intercambio de datos entre sistemas y aplicaciones.
• El rastreo de los cambios a lo largo del tiempo a través de un sistema de control de versiones bien documentado.
• Aumentar el valor de los códigos de referencia, si se reutilizan y referencian ampliamente.

Más acerca de Re3gistry:

Continuamos con la serie de posts sobre Chat GPT-3. La expectación levantada por el sistema conversacional justifica con creces la publicación de varios artículos sobre sus características y aplicaciones. En este post, profundizamos sobre una de las últimas novedades publicadas por openAI relacionadas con Chat GPT-3. En este caso introducimos su API, es decir, su interfaz de programación con la que podemos integrar Chat GPT-3 en nuestras propias aplicaciones.

Introducción.

En nuestro último post sobre Chat GPT-3 realizamos un ejercicio de co-programación o programación asistida en el que le solicitamos a la IA que nos escribiera un programa sencillo, en lenguaje de programación R, para visualizar un conjunto de datos. Como vimos en el post, utilizamos la propia interfaz disponible de Chat GTP-3. La interfaz es muy minimalista y funcional, tan solo tenemos que preguntar a la IA en el cuadro de texto y ella nos contesta en el cuadro de texto posterior. Tal y como concluimos en el post, el resultado del ejercicio fue más que satisfactorio. Sin embargo, también detectamos algunos puntos de mejora. Por ejemplo, la interfaz estándar puede resultar un poco lenta. Para un ejercicio largo, con múltiples interacciones conversacionales con la IA (un diálogo largo), la interfaz tarda bastante en escribir las respuestas. Varios usuarios reportan la misma sensación y por eso algunos, como este desarrollador, han creado su propia interfaz con el asistente conversacional para mejorar su velocidad de respuesta.

Pero, ¿cómo es posible esto? La razón es sencilla, gracias al API de Chat GPT-3. En este espacio de divulgación hemos hablado mucho sobre las APIs en el pasado. No en vano, las APIs son los mecanismos estándar en el mundo de las tecnologías digitales para integrar servicios y aplicaciones. Cualquier app en nuestro smartphone hace uso de las APIs para mostrarnos los resultados. Cuando consultamos el tiempo, los resultados deportivos o el horario del transporte público, las apps hacen llamadas a las APIs de los servicios para consultar la información y mostrar los resultados.

El API de Chat GPT-3

Como cualquier otro servicio actual, openAI pone a disposición de sus usuarios una API con la que poder invocar (llamar) a sus diferentes servicios basados en el modelo entrenado de lenguaje natural GPT-3. Para usar el API, tan solo tenemos que iniciar sesión con nuestra cuenta en https://platform.openai.com y localizar el menú (superior derecha) View API Keys. Hacemos click en create a new secret key y ya tenemos nuestra nueva clave de acceso al servicio.

¿Qué hacemos ahora? Bien, para ilustrar lo que podemos hacer con esta nueva y flamante clave veamos algunos ejemplos:

Como decíamos en la introducción, podemos querer probar interfaces alternativas a Chat GPT-3 como https://www.typingmind.com/. Cuando accedemos a esta web, lo primero que debemos hacer es ingresar nuestra API Key.

Una vez dentro, hagamos un ejemplo y veamos cómo se comporta esta nueva interfaz. Preguntemos a Chat GPT-3 ¿Qué es datos.gob.es?

Veamos ahora otra aplicación del API de Chat GPT-3.

Acceso programático con R  para acceder a Chat GPT-3 de modo programático (o lo que es lo mismo, con algunas líneas de código en R tenemos acceso a la potencia conversacional del modelo GPT-3). Esta demostración está basada en el reciente post publicado en R Bloggers. Vamos a acceder a Chat GPT-3 de modo programático con el siguiente ejemplo.  

En este ejemplo, utilizamos código en R para hacer una llamada HTTPs de tipo POST y le preguntamos a Chat GPT-3 ¿Qué es datos.gob.es? Vemos que estamos utilizando el modelo gpt-3.5-turbo que, tal y como se especifica en la documentación está indicado para tareas de tipo conversacional. Toda la información sobre la API y los diferentes modelos está disponible aquí. Pero, veamos el resultado:

¿Nada mal verdad? Como dato curioso podemos ver que unas pocas llamadas al API de Chat GPT-3 han tenido el siguiente uso del API:

El uso del API se cotiza por tokens (algo similar a las palabras) y los precios públicos pueden consultarse aquí. En concreto el modelo que estamos utilizando tiene estos precios:

Para pequeñas pruebas y ejemplos, nos lo podemos permitir. En caso de aplicaciones empresariales para entornos productivos existe un modelo premium que permite tener un control de los costes sin depender tanto del uso.

Conclusión

Como no podía ser de otra manera, Chat GPT-3 habilita un API para proporcionar acceso programático a su motor conversacional. Este mecanismo permite la integración de aplicaciones y sistemas (es decir, todo lo que no son humanos) abriendo la puerta al despegue definitivo del Chat GPT-3 como modelo de negocio. Gracias a este mecanismo, el buscador Bing ahora integra Chat GPT-3 para respuestas a las búsquedas en modo conversacional. De la misma forma, Microsoft Azure acaba de anunciar la disponibilidad de Chat GPT-3 como un nuevo servicio de la nube pública. Sin lugar a dudas, en las próximas semanas veremos comunicaciones de todo tipo de aplicaciones, apps y servicios, conocidos y desconocidos, anunciando su integración con Chat GPT-3 para mejorar las interfaces conversacionales con sus clientes. Nos vemos en el próximo episodio, quién sabe sin con GPT-4.

Contenido elaborado por Alejandro Alija, experto en Transformación Digital.

Los contenidos y los puntos de vista reflejados en esta publicación son responsabilidad exclusiva de su autor.

En este artículo recopilamos una serie de infografías dirigidas tanto a publicadores como reutilizadores que trabajen con datos abiertos. En ellas se muestras normas y buenas prácticas para facilitar tanto la publicación como el tratamiento de datos.

1. DCAT-AP-ES: Guías y materiales de apoyo para facilitar su uso

Publicada: agosto 2025 Este nuevo modelo de metadatos adopta las directrices del esquema europeo de intercambio de metadatos DCAT-AP (Data Catalog Vocabulary-Aplication Profile) con algunas restricciones y ajustes adicionales. Accede aquí

2. Guía para el despliegue de portales de datos abiertos

Publicada: abril 2025 Esta infografía resume buenas prácticas y recomendaciones para diseñar, desarrollar y desplegar portales de datos abiertos en el ámbito municipal. En concreto recoge: marco estratégico, requisitos generales y pautas técnicas y funcionales. Accede aquí

3. Ley de Datos (Data Act o DA)

Publicada: febrero 2024 La Ley de Datos (Data Act) es una regulación de la Unión Europea para facilitar la accesibilidad de los datos de forma horizontal. Es decir, estableciendo principios y directrices para todos los sectores, haciendo hincapié en el acceso justo a los datos, los derechos de los usuarios y la protección de los datos personales. Descubre cuáles son sus claves en esta infografía. También se ha creado una versión a una página para facilitar su impresión: accede aquí Accede aquí

4. Reglamento europeo de gobernanza de datos (Data Governance Act o DGA)

Publicada: enero 2024 El Reglamento europeo de gobernanza de datos (Data Governance Act o DGA) es un instrumento horizontal para regular la reutilización de datos e impulsar su intercambio bajo los principios y valores de la Unión Europea (UE). Descubre cuáles son sus claves en esta infografía. Accede aquí También se ha creado una versión a una página para facilitar su impresión: accede aquí

5. Las claves de las especificaciones UNE sobre el dato

Publicada: septiembre 2023 Todo tipo de instituciones deben disponer de datos bien gobernados, gestionados y con niveles adecuados de calidad, siendo necesaria una metodología de evaluación común. La siguiente infografía resumen cuáles son las claves de las Especificaciones UNE sobre el dato y sus principales ventajas. Accede aquí

6. Principales obligaciones de la Ley 37/2007

Publicada: marzo 2023 En aplicación de la última Directiva europea de datos abiertos, se ha modificado la Ley 37/2007 para que incida en el concepto de los datos abiertos desde el diseño y por defecto. Esta infografía destaca los principales cambios de la normativa. Accede aquí

7. Cómo crear un plan de medidas para impulsar la apertura y reutilización de datos abiertos

Publicada: noviembre 2022 Esta infografía recoge los diferentes elementos que debe contener un Plan de medidas de impulso de la apertura y reutilización de datos abiertos. El objetivo es que las unidades responsables de la apertura puedan trazar una hoja de ruta factible de apertura de datos, que además permita su seguimiento y evaluación. Accede aquí

8. 8 guías para mejorar la publicación y el tratamiento del dato

Publicada: octubre 2022 Desde datos.gob.es hemos elaborado diferentes guías para ayudar a publicadores y reutilizadores a la hora de preparar los datos datos para su publicación y/o análisis. En esta infografía te resumimos el contenido de ocho de ellas. Accede aquí

9. Pautas generales para garantizar la calidad de los datos abiertos

Publicada: septiembre 2022 Esta infografía detalla una serie pautas generales para garantizar la calidad de los datos abiertos, como, por ejemplo, utilizar una codificación de caracteres estandarizada, evitar la duplicidad de registros o incorporar variables con información geográfica. Accede aquí

10. Pautas para asegurar la calidad usando formatos específicos de datos

Publicada: septiembre 2022 Esta infografía recoge pautas concretas para asegurar la calidad de los datos abiertos según el formato de datos utilizado. Se han incluido pautas específicas para los formatos CSV, XML, JSON, RDF y APIs. Accede aquí

11. Normas para un correcto gobierno del dato

Publicada: mayo 2022 Esta infografía recoge la normas a tener en cuenta para un correcto gobierno del dato, según la Asociación Española de Normalización (UNE) . Estas normas se basan en 4 principios: Gobernanza, Gestión, Calidad y Seguridad y privacidad de datos. Accede aquí

12. APIs para el acceso a datos abiertos

Publicada: enero 2022 Muchos portales de datos abiertos en España ya cuentan con sus propias APIs para facilitar el acceso a datos y metadatos. Esta infografía muestra algunos ejemplos a nivel nacional, autonómico y local, incluyendo información sobre la API de datos.gob.es. Accede aquí

España fue el segundo país del mundo que más turistas recibió durante 2019, con 83,8 millones de visitantes. La actividad turística supuso ese año el 12,4% del PIB, empleando a más de 2,2 millones de personas (12,7% del total). Se trata por tanto de un sector fundamental para nuestra economía.

Estas cifras se han visto reducidas debido a la pandemia, pero se espera que el sector se vaya recuperando en los próximos meses. A ello pueden ayudar los datos abiertos. Contar con información actualizada puede generar beneficios a todos los actores implicados en esta industria:

• Turistas: El open data ayuda a los turistas a planificar sus viajes, dotándoles de la información necesaria para elegir donde alojarse o qué actividades realizar. La información actualizada que pueden proporcionar los datos abiertos cobra especial importancia en tiempos de COVID. Existen distintos portales que recogen información y visualizaciones de las restricciones de viaje, como Humanitarian Data Exchange, de las Naciones Unidas. Esta web alberga un mapa interactivo actualizado diariamente con las restricciones de viaje por país y compañía aérea.
• Empresas. Las empresas pueden generar distintas aplicaciones dirigidas a los viajeros, con información de utilidad.  Además, analizando los datos, los establecimientos turísticos pueden detectar mercados y destinos sin explotar. También pueden personalizar sus ofertas e incluso crear sistemas de recomendaciones que ayuden a la promoción de diversas actividades, con un impacto positivo en la experiencia de los viajeros.
• Administraciones Públicas. Cada vez más gobiernos están implementando soluciones para captar y analizar datos de distintas fuentes en tiempo real, con el fin de conocer mejor el comportamiento de sus visitantes. Ejemplo de ello son Segovia, Mallorca y Gran Canaria. Gracias a estas herramientas podrán definir estrategias y tomar decisiones informadas, por ejemplo, dirigidas a evitar masificaciones. En este sentido, herramientas como Affluences permiten informar de la ocupación de museos, piscinas y tiendas en tiempo real, y obtener predicciones para las sucesivas franjas horarias.

Los beneficios de contar con datos de calidad relacionados con el turismo es tal que no es de extrañar que el Gobierno de España haya elegido este sector como prioritario a la hora de crear espacios de datos que permitan la compartición voluntaria de datos entre organizaciones. De esta forma se podrán cruzar datos de distintas fuentes, enriqueciendo los diversos casos de uso.

Los datos utilizados en este ámbito son muy diversos: datos sobre consumo, transporte, actividades culturales, tendencias económicas o incluso sobre la predicción meteorológica. Pero para poder aprovechar bien estos datos altamente dinámicos es necesarios que estén a disposición de los usuarios en formatos adecuados, actualizados y que el acceso se pueda automatizar a través de interfaces de programación de aplicaciones (APIs).

Ya son muchas las organizaciones que ofrecen datos a través de APIs. En esta infografía puedes ver varios ejemplos ligados a nuestro país a nivel nacional, autonómico y local. Pero además de portales de datos generalistas, también encontramos APIs en plataformas de datos abiertos ligadas exclusivamente al sector turismo. En la siguiente infografía puedes ver varios ejemplos:

Haz clic aquí para ver la infografía en tamaño completo y en su versión accesible

¿Conoces más ejemplos de APIs u otros recursos que faciliten el acceso a los datos abiertos relacionados con el turismo? ¡Déjanos un comentario o escribe a datos.gob.es!

Contenido elaborado por el equipo de datos.gob.es.

El pasado diciembre el Congreso de los Diputados aprobó el Real Decreto-ley 24/2021, que incluía la transposición de la Directiva (UE) 2019/1024, relativa a los datos abiertos y la reutilización de la información del sector público. Con este Real Decreto se modifica la Ley 37/2007 sobre reutilización de la información del sector público, incluyendo nuevos requisitos para los organismos públicos, entre los que se encuentra el facilitar el acceso a los datos de alto valor.  

Los datos de alto valor son aquellos cuya reutilización está asociada a considerables beneficios para la sociedad, el medio ambiente y la economía. Inicialmente, la Comisión Europea destacó como datos de alto valor aquellos pertenecientes a las categorías de datos geoespaciales, ambientales, meteorológicos, estadísticos, relativos a sociedades y de movilidad, aunque estas clases pueden ser ampliadas tanto por, la Comisión como por el Ministerio de Asuntos Económicos y Transformación Digital a través de la Oficina del Dato. De acuerdo con la Directiva, este tipo de datos “se pondrán a disposición para su reutilización en un formato legible por máquina, a través de interfaces de programación de aplicaciones adecuadas y, cuando proceda, en forma de descarga masiva”. Es decir, entre otras cuestiones, se hace necesario el contar con una API. 

¿Qué es una API? 

Una interfaz de programación de aplicaciones o API (la abreviatura en inglés de Application Programming Interfaces) es un conjunto de definiciones y protocolos que permite el intercambio de información entre sistemas. Cabe destacar que existen distintos tipos de APIs en base a su arquitectura, protocolos de comunicación y sistemas operativos. 

Las APIs suponen una serie de ventajas para los desarrolladores, ya que permiten automatizar el consumo de datos y metadatos, facilitan la descarga masiva y optimizan la recuperación de información al admitir funcionalidades de filtrado, ordenación y paginación. Todo ello repercute en un ahorro tanto económico como de tiempo.  

En este sentido, muchos portales de datos abiertos de nuestro país ya cuentan con sus propias APIs para facilitar el acceso a datos y metadatos. En la siguiente infografía puedes ver algunos ejemplos a nivel nacional, autonómico y local, incluyendo información sobre la API de datos.gob.es. La infografía también incluye información breve sobre qué es una API y qué se necesita para poder utilizarlas. 

Haz clic aquí para ver la infografía en tamaño completo y en su versión accesible

Estos ejemplos ponen de manifiesto el esfuerzo que los organismos públicos de nuestro país están haciendo para facilitar el acceso a la información que custodian de forma más eficiente y automatizada, con el fin de impulsar la reutilización de sus datos abiertos.  

En datos.gob.es contamos con una Guía práctica para la publicación de datos abiertos usando APIs donde se detallan una serie de pautas y buenas prácticas para definir e implementar este mecanismo en un portal open data. 

Contenido elaborado por el equipo de datos.gob.es.