Archivos de datos, API y descubrimiento

Distintos usuarios tienen diferentes necesidades cuando se trata de acceder a los datos de OCDS.

Los datos sobre La Mejores Prácticas en la Web sugiere que “los datos deben estar disponibles en múltiples formatos de datos” con el fin de aumentar el número de usuarios diferentes, las herramientas y aplicaciones que pueden procesar estos datos.

La importancia de ciertos formatos sobre otros va a depender de la prioridad de los casos de uso para cada implementación OCDS, pero lo invitamos a considerar:

  • Descargas masivas - empaquetando varias entregas o múltiples registros en uno o más archivos para que los usuarios los descarguen e importen en las herramientas locales.

  • Entrega individual y descargas de registros - proporcionando un URI en el cual puede obtenerse cada entrega o registro. Esto es crucial para el nivel 4 ☆ de publicación de datos.

  • ** CSV y serializaciones en hojas de cálculo ** - proveer múltiples entregas o records compilados para descargar, permitiendo a los usuarios trabajar con los datos directamente en un software de hojas de cálculo u otras herramientas

  • **Acceso a través de APIs ** - permite el acceso interactivo a sus datos.

Descargas masivas

El paquete de entregas y el paquete de registros pueden dar ** acceso masivo ** a las entregas y registros, respectivamente.

Sin embargo, los archivos muy grandes pueden ser difíciles de descargar y procesar. En la siguiente sección se ofrecen buenas prácticas sugeridas que ayudarán a los usuarios a acceder a estos datos. Estas prácticas no son requisitos del estándar, sino que se basan en experiencias para maximizar el número de usuarios capaces de trabajar con conjuntos de datos con hardware y software existentes.

Límites de tamaño de archivo

Cuando se generan paquetes para descarga masiva, se aplican los siguientes límites:

  • Los paquetes OCDS descomprimidos no deben de exceder 1 GB cada uno;

  • Los paquetes OCDS comprimidos no deben exceder 10 mb cada uno;

  • Un paquete OCDS único debe contener un máximo de 250,000 adjudicaciones o contratos;

Cuando es probable que un archivo exceda estos límites, las entregas o registros deben de dividirse en múltiples documentos. Las descargas masivas que se generan dinámicamente no están obligados a aplicar estos límites, aunque los publicadores deben considerar guiar a los usuarios cuando una consulta puede generar un archivo muy grande.

Segmentación de archivos

Cuando los límites sugeridos comprenden la publicación de muchos archivos, los publicadores deben considerar la manera de dividir los datos en múltiples archivos.

Para entregas, los publicadores pueden:

  1. Segmentar por fecha de entrega- poniendo todas las entregas que salieron en un mismo día, mes o año en el mismo archivo;

  2. Segmentar por identificador de proceso de contrataciones- poniendo todas las entregas relacionadas a un conjunto de identificadores de proceso de contrataciones en el mismo paquete;

Para registros, los publicadores pueden segmentar por la primera fecha de entrega asociada con un proceso de contrataciones, o por identificador de proceso de contrataciones.

Seguir estos enfoques evitará los ‘saltos’ entre los archivos de entregas y registros cuando se actualicen los archivos masivos.

Compresión

Los paquetes OCDS pueden comprimirse para ahorrar en espacio de disco y en ancho de banda.

Si se comprimen paquetes, los publicadores deben de usar el formato ZIP.

Servir archivos

El servidor web que da acceso a archivos masivos debe de reportar correctamente la cabecera HTTP Last-Modified para que las aplicaciones consumidoras necesiten descargar sólo los archivos actualizados.

Entregas y registros individuales

Para alcanzar 4 ☆ en la publicación OCDS, se requiere que cada entrega y registro sea accesible en una URI permanente. Esto puede lograrse haciendo lo siguiente:

(a) Archivando un paquete de entregas con una única entrega en un sistema de archivos accesible a través de la Web al momento de ser creada, y después fusionar regularmente estas entregas para compilar archivos de registro individuales en el mismo sistema de archivos. Una manera de hacer esto podría ser tener una carpeta para cada ocid y poner las entregas y registro relacionados con ese proceso en esa carpeta.

(B) Proporcionar acceso a las entregas y registros a través de una API.

Note que el segundo enfoque necesita un API para mantener un historial de revisión completo en cada proceso de contrataciones, para que se puedan dar entregas de cada etapa del proceso de contrataciones.

Los publicadores deben considerar cómo asegurar que las URIs se mantengan estables, incluso si ocurre un cambio de sistemas.

Serializaciones planas

La página serialización proporciona detalles sobre cómo generar versiones “planas” de datos OCDS para su uso en un software de hoja de cálculo.

Los mismos principios que se discutieron anteriormente sobre archivos masivos deben aplicarse a descargas CSV o Excel de los datos.

Descubrimiento y APIs

Hay miles de organizaciones que deberían ser capaces de publicar datos de contrataciones abiertas. Como resultado, mantener un registro central de todos los datos publicados es impráctico. Debido a eso, OCDS propone un patrón común para el descubrimiento de entregas y registros.

Para el descubrimiento de conjuntos de datos masivos y la ubicación de cualquier fuente de datos, se propone el uso de un archivo data.json.

Para el descubrimiento de entregas y registros individuales, recomendamos utilizar Atom feeds.

Conjunto de datos y descubrimiento de feeds

Los publicadores pueden dar un documento data.json para describir la ubicación de todos los archivos masivos OCDS disponibles para descarga.

Esto debe seguir la estructura propuesta por el US Project Open Data con:

  • Cada registro que contiene un bloque de distribución con al menos un accessURL apuntando a los datos OCDS.

  • Cada registro que contiene ‘open-contracting-data’ y ‘open-contracting-release’ o ‘open-contracting-record’ en la matriz de palabras clave.

  • accessLevel configurado adecuadamente

Además, el documento data.json puede contener uno o más registros con la palabra clave ‘open-contracting-feed’ y ‘open-contracting-release’ o ‘open-contracting-record’ y apuntando a través de un accessURL en su bloque de distribución a un documento de atom feed.

Feeds

Los publicadores exponiendo entregas y registros individuales, de paquetes que se actualizan regularmente en pequeños conjuntos, deben de dar uno o más Atom feeds que los indexan, y proporcionar un mecanismo fácil para que los usuarios descubran entregas y registros recientemente publicados o actualizados.

El link a la entrega o registro debe de darse via una etiqueta <link>, y la fecha actualizada de la entrada debe de reflejar la fecha actualizada de esa entrega o registro. El <id> debe reflejar el identificador de la entrega, o el ocid para registros.

La etiqueta release.tag debe de contenerse en un elemento <category> del feed.

Los feeds que requieran paginación debe seguir el enfoque establecido en RFC 5005.

Well Known

Las futuras implementaciones de OCDS explorarán el uso del protocolo /.well-known/ para declarar una ubicación para almacenar un archivo data.json.

En la actualidad, tales archivos pueden ser alojados en cualquier lugar, y las aplicaciones de consumo apuntadas hacia ellos manualmente.

Se ha elegido la estructura data.json para permitir que las organizaciones que sigan este enfoque incluyan ‘open-contracting-data’ etiquetada dentro de sus mecanismos de descubrimiento de datos existentes y dada la disponibilidad de un complemento para el CKAN ampliamente utilizado, que también impulsará la exposición de archivos de data.json.

Vinculación de datos

Para el nivel 5 ☆ publicación de datos OCDS, los publicadores deben tratar de usar URIs en sus bases de datos, enlazando a otras fuentes de datos legibles por máquina en un nivel entidad por entidad.