Referencia de Registros¶

Aunque pueden haber múltiples entregas sobre un proceso de contrataciones, debe haber un solo registro por proceso de contrataciones, uniendo todas las entregas disponibles para el proceso de contrataciones.

Nota: Si se encuentran conflictos entre este texto, y el texto dentro del esquema, el esquema tiene precedencia.

Navegando el esquema

Esta página presenta el esquema del paquete de entregas en un navegador interactivo. También puede descargar la versión canónica del esquema del paquete de entregas como Esquema JSON, o verlo en un navegador interactivo.

Metadatos del paquete¶

Los registros deben publicarse dentro de un paquete de registros. El paquete de registros proporciona metadatos sobre el(los) registro(s) que contiene.

Título	Descripción	Tipo	Formato	Requerido
`uri`		string	uri	Required
Identificador de paquete	La URI de este paquete que lo identifica de manera única en el mundo.
`version`		string		Required
Versión del esquema de OCDS	La versión del esquema de OCDS usada en este paquete, expresada como major.minor. Por ejemplo 1.0 o 1.1
`extensions`		array[string]
Extensiones OCDS	Una lista de extensiones OCDS que se utiliza en este paquete, en el cual cada item es el URL de un archivo extension.json.
`publisher`		object		Required
Publicador	Información que identifica de manera única al publicador de este paquete.
`publisher/name`		string		Required
Nombre	El nombre de la organización o departamento responsable de publicar estos datos.
`publisher/scheme`		[string, null]
Esquema	El esquema que tiene los identificadores únicos utilizados para identificar el artículo que se identifica.
`publisher/uid`		[string, null]
uid	El ID único para esta entidad en el esquema de identificadores dado.
`publisher/uri`		[string, null]	uri
URI	Una URI para identificar al publicador.
`license`		[string, null]	uri
Licencia	Un enlace a la licencia que aplica para los datos en este paquete. Se recomiendan licencias de Entrega al Dominio Público o que cumplan con la Open Definition. Se deberá usar la URI canónica de la licencia. Los documentos enlazados desde este archivo pueden estar bajo otras condiciones de licencia.
`publicationPolicy`		[string, null]	uri
Política de publicación	Un enlace a un documento que describe la política de publicación de los publicadores.
`publishedDate`		string	date-time	Required
Fecha de publicación	La fecha en que se publicó este paquete. Si se generó 'bajo demanda', esta fecha debe de reflejar la fecha del último cambio y los contenidos subyacentes del paquete.
`packages`		array[string]
Paquetes	Una lista de URIs de todos los paquetes de entregas que se usaron para crear este paquete de registros.
`records`		array[Registro]		Required
Registros	Los registros para este paquete de datos. See record

Consulte la guía de licencias para obtener más detalles sobre cómo seleccionar una licencia y publicar información de esta.

Consulte la guía de política de publicación para obtener más detalles sobre qué incluir en una política de publicación.

Los metadatos del paquete de registro tienen dos diferencias frente a los metadatos del paquete de entrega:

En vez de una lista de releases, un paquete de registros tiene una lista de records que contiene uno o más registros.
Un paquete de registros tiene una lista de packages, para vincular los paquetes de entregas que se utilizaron para preparar los registros.

El siguiente ejemplo muestra todos los metadatos del paquete y los campos del registro.

⊕{...}⊖{
    "uri": "https://standard.open-contracting.org/examples/records/ocds-213czf-000-00002-merge.json",
    "publisher": ⊕{...},
    "publishedDate": "2016-03-05T13:02:00Z",
    "license": "http://opendatacommons.org/licenses/pddl/1.0/",
    "publicationPolicy": "https://github.com/open-contracting/sample-data/",
    "version": "1.1",
    "packages": ⊕[ ... ]⊖[
        "https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-award1.json",
        "https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-award2.json",
        "https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-tender.json",
        "https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-tender-update.json",
       ⊕"https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-tender-amendment.js ..."⊖        "https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-tender-amendment.json"
    ],
    "records": ⊕[ ... ]⊖[
       ⊕{...}⊖{
            "ocid": "ocds-213czf-000-00002",
            "releases": ⊕[ ... ],
            "compiledRelease": ⊕{...},
            "versionedRelease": ⊕{...}
        }
    ]
}

Estructura de un registro¶

Un registro debe contener un ocid y todas las entregas sobre el proceso de contrataciones. Como tal, un registro funciona como un índice de todas las entregas sobre un proceso de contrataciones.

Un registro debería contener un objeto compiledRelease, que representa el estado del proceso de contrataciones al momento de la publicación del registro.

Un registro ** puede ** contener un objeto versionedRelease, que agrega, en un solo objeto, todos los valores de todos los campos de todas las entregas. La entrega versionada está diseñada para que sea fácil ver cómo cambian los valores de una entrega a otra, y generalmente serán generados por los usuarios de datos en vez de los publicadores.

Entregas¶

Cada entrega en un registro puede proporcionarse como una entrega vinculada o como una entrega incrustada.

Entregas vinculadas¶

Una entrega vinculada sigue un esquema simple:

Título	Descripción	Tipo	Formato	Requerido
`url`		[string, null]	uri	Required
URL de la Entrega	La URL de la entrega que contiene la URL del paquete con el `id` de entrega anexado usando un identificador de fragmento e.j. https://standard.open-contracting.org/1.1/es/examples/tender.json#ocds-213czf-000-00001.
`date`		string	date-time	Required
Fecha de entrega	La fecha de una entrega. Debe ser igual al valor del campo `date` de la entrega. Esto se usa para ordenar las entregas en la lista en orden cronológico.
`tag`		array[string]
Etiqueta de entrega	Las etiquetas de la entrega. Deben ser iguales al valor del campo `tag` de la entrega. Esto da contexto adicional cuando se revisa un registro para ver qué tipos de entrega se incluyen para este ocid.

Para cada valor de url, debe ser posible que una aplicación de consumo recupere el paquete de entregas en la URL e identifique la entrega dentro de él. Dado que un paquete de entregas puede contener múltiples entregas, para que una entrega vinculada identifique una entrega específica a través de su campo url, el id de la entrega debe adjuntarse a la URL del paquete de entrega utilizando un identificador de fragmento.

El siguiente ejemplo muestra el uso de entregas vinculadas.

⊕{...}⊖{
    "ocid": "ocds-213czf-000-00002",
    "releases": ⊕[ ... ]⊖[
       ⊕{...}⊖{
            "url": ⊕"https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-award1.json#ocds-21 ...",
            "date": "2016-03-01T09:30:00Z",
            "tag": ⊕[ ... ]⊖[
                "award"
            ]
        },
       ⊕{...}⊖{
            "url": ⊕"https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-award2.json#ocds-21 ...",
            "date": "2016-03-03T09:30:00Z",
            "tag": ⊕[ ... ]⊖[
                "award"
            ]
        },
       ⊕{...}⊖{
            "url": ⊕"https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-tender.json#ocds-21 ...",
            "date": "2016-01-01T09:30:00Z",
            "tag": ⊕[ ... ]⊖[
                "tender"
            ]
        },
       ⊕{...}⊖{
            "url": ⊕"https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-tender-update.json# ...",
            "date": "2016-01-31T09:30:00Z",
            "tag": ⊕[ ... ]⊖[
                "tenderUpdate"
            ]
        },
       ⊕{...}⊖{
            "url": ⊕"https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-tender-amendment.js ...",
            "date": "2016-02-05T10:30:00Z",
            "tag": ⊕[ ... ]⊖[
                "tenderAmendment"
            ]
        }
    ],
    "compiledRelease": ⊕{...},
    "versionedRelease": ⊕{...}
}

Arriba, la primera entrega vinculada tiene el valor de url de https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-award1.json#ocds-213czf-000-00002-01-award1. La primera parte (https://standard.open-contracting.org/examples/releases/ocds-213czf-000-00002-01-award1.json) es la URL del paquete de entregas, y el identificador de fragmento (ocds-213czf-000-00002-01-award1) es el id de la entrega.

Los valores de id de entrega sólo deben ser únicos dentro del alcance de un proceso de contratación: es decir, dentro del alcance de un valor de ocid. Así, una aplicación de consumo necesita usar ese identificador de fragmento en combinación con el ocid del registro para identificar la entrega correspondiente dentro del paquete de entregas.

Entregas embebidas¶

Una entrega incrustada sigue el esquema de entrega. En otras palabras, en vez de vincularse a una entrega dentro de un paquete de entrega como se mencionó anteriormente, la entrega se incluye en su totalidad dentro del registro.

El siguiente ejemplo muestra el uso de entregas incrustadas.

⊕{...}⊖{
    "compiledRelease": ⊕{...},
    "ocid": "ocds-213czf-000-00001",
    "releases": ⊕[ ... ]⊖[
       ⊕{...}⊖{
            "ocid": "ocds-213czf-000-00001",
            "id": "ocds-213czf-000-00001-01-planning",
            "date": "2009-03-15T14:45:00Z",
            "language": "en",
            "tag": ⊕[ ... ]⊖[
                "planning"
            ],
            "initiationType": "tender",
            "parties": ⊕[ ... ],
            "buyer": ⊕{...},
            "planning": ⊕{...},
            "tender": ⊕{...}
        },
       ⊕{...}⊖{
            "ocid": "ocds-213czf-000-00001",
            "id": "ocds-213czf-000-00001-02-tender",
            "date": "2010-03-15T09:30:00Z",
            "language": "en",
            "tag": ⊕[ ... ]⊖[
                "tender"
            ],
            "initiationType": "tender",
            "parties": ⊕[ ... ],
            "buyer": ⊕{...},
            "tender": ⊕{...}
        },
       ⊕{...}⊖{
            "ocid": "ocds-213czf-000-00001",
            "id": "ocds-213czf-000-00001-03-tenderAmendment",
            "date": "2010-03-20T10:45:00Z",
            "language": "en",
            "tag": ⊕[ ... ]⊖[
                "tenderAmendment"
            ],
            "initiationType": "tender",
            "parties": ⊕[ ... ],
            "buyer": ⊕{...},
            "tender": ⊕{...}
        },
       ⊕{...}⊖{
            "ocid": "ocds-213czf-000-00001",
            "id": "ocds-213czf-000-00001-03-tenderUpdate",
            "date": "2010-03-20T09:45:00Z",
            "language": "en",
            "tag": ⊕[ ... ]⊖[
                "tenderUpdate"
            ],
            "initiationType": "tender",
            "parties": ⊕[ ... ],
            "buyer": ⊕{...},
            "tender": ⊕{...}
        },
       ⊕{...}⊖{
            "ocid": "ocds-213czf-000-00001",
            "id": "ocds-213czf-000-00001-04-award",
            "date": "2010-05-10T09:30:00Z",
            "language": "en",
            "tag": ⊕[ ... ]⊖[
                "award"
            ],
            "initiationType": "tender",
            "parties": ⊕[ ... ],
            "buyer": ⊕{...},
            "awards": ⊕[ ... ]
        },
       ⊕{...}⊖{
            "ocid": "ocds-213czf-000-00001",
            "id": "ocds-213czf-000-00001-05-contract",
            "date": "2010-05-10T10:30:00Z",
            "language": "en",
            "tag": ⊕[ ... ]⊖[
                "contract"
            ],
            "initiationType": "tender",
            "parties": ⊕[ ... ],
            "buyer": ⊕{...},
            "awards": ⊕[ ... ],
            "contracts": ⊕[ ... ]
        },
       ⊕{...}⊖{
            "ocid": "ocds-213czf-000-00001",
            "id": "ocds-213czf-000-00001-06-implementation",
            "date": "2011-01-10T09:30:00Z",
            "language": "en",
            "tag": ⊕[ ... ]⊖[
                "implementation"
            ],
            "initiationType": "tender",
            "parties": ⊕[ ... ],
            "buyer": ⊕{...},
            "awards": ⊕[ ... ],
            "contracts": ⊕[ ... ]
        }
    ]
}

Comparando opciones¶

Las consideraciones son:

Utilizar entregas vinculadas genera archivos de menor tamaño, en comparación a utilizar entregas incrustadas.
Desde la perspectiva del usuario, el contenido de las entregas es más fácil de acceder como entregas incrustadas que como entregas vinculadas (lo cual requiere el proceso de recuperación que se describió anteriormente).
Desde la perspectiva de un publicador, usar entregas vinculadas involucra publicar paquetes de entregas y construir valores de url, mientras que utilizar entregas incrustadas no involucra esto.

Entrega compilada¶

La entrega compilada es la última versión de todos los datos sobre un proceso de contratación. En otras palabras, proporciona una instantánea o imagen del estado actual de un proceso de contrataciones.

La entrega compilada sigue el esquema de entrega, con la excepción de cualquier campo en el que se declara "omitWhenMerged": true.

El proceso para crear una entrega compilada a partir de entregas individuales se describe en la referencia de fusionar

Entrega versionada¶

Una entrega versionada contiene todos los valores de todos los campos de todas las entregas. Para cada campo, se describe el historial de valores desde el valor inicial hasta el valor actual, incluyendo el id, date y tag de la entrega en la que el valor se modificó.

La información versionada es importante para muchos casos de uso relacionados al monitoreo de los contratos. Sin embargo, puede incrementar substancialmente el tamaño de los archivos. Los publicadores pueden considerar publicar copias de los registros con y sin entregas versionadas.

Si la entrega versionada no se proporciona, entidades externas pueden generarla al procesar las entregas en el registro de acuerdo a lo indicado en la referencia de fusionar.

El siguiente ejemplo muestra los valores versionados de un solo campo. Esto muestra que la cantidad cambió entre la etapa de planificación y la etapa de licitación, mientras que la moneda no cambió.

⊕{...}⊖{
    "amount": ⊕[ ... ]⊖[
       ⊕{...}⊖{
            "releaseID": "ocds-213czf-000-00002-01-tender",
            "releaseDate": "2016-01-01T09:30:00Z",
            "releaseTag": ⊕[ ... ]⊖[
                "tender"
            ],
            "value": 1000
        },
       ⊕{...}⊖{
            "releaseID": "ocds-213czf-000-00002-01-tender-amendment",
            "releaseDate": "2016-02-05T10:30:00Z",
            "releaseTag": ⊕[ ... ]⊖[
                "tenderAmendment"
            ],
            "value": 2000
        }
    ],
    "currency": ⊕[ ... ]
}