pycsw is an OGC CSW server implementation written in Python. pycsw fully implements the OpenGIS Catalogue Service Implementation Specification [Catalogue Service for the Web]. Initial development started in 2010 (more formally announced in 2011). The project is certified OGC Compliant, and is an OGC Reference Implementation. pycsw allows for the publishing and discovery of geospatial metadata via numerous APIs (CSW 2/CSW 3, OpenSearch, OAI-PMH, SRU). Existing repositories of geospatial metadata can also be exposed, providing a standards-based metadata and catalogue component of spatial data infrastructures. pycsw is Open Source, released under an MIT license, and runs on all major platforms (Windows, Linux, Mac OS X). Please read the docs at https://pycsw.org/docs for more information.
Metadata models (such as DCAT, ISO19139. MCF) support translation options for various elements (title, abstract, organization).
Storing translations
For backwards compatibility it could be interesting to keep the current, single language model and store translations in a linked table as:
record-id
key
value
language
a3e55-12ec-463
title
Distribución de especies exóticas en los bosques del Mediterráneo.
es
This will cause a challenge in translations within nested elements, such as keywords, distributions, contacts. Maybe here the translations can be included in the nested structure.
Dialects
Following the language header conventions, we best support the main langauge as well as the dialects en-us, en-uk, en-ca.
OGCAPI - Records
In OGCAPI - Records typically a record is returned in a single language. The language requested (via accept-language header) would be selected from the available translations. With a ?lang=en users would be able to override the language header provided by the browser.
Metadata models (such as DCAT, ISO19139. MCF) support translation options for various elements (title, abstract, organization).
Storing translations
For backwards compatibility it could be interesting to keep the current, single language model and store translations in a linked table as:
This will cause a challenge in translations within nested elements, such as keywords, distributions, contacts. Maybe here the translations can be included in the nested structure.
Dialects
Following the language header conventions, we best support the main langauge as well as the dialects en-us, en-uk, en-ca.
OGCAPI - Records
In OGCAPI - Records typically a record is returned in a single language. The language requested (via accept-language header) would be selected from the available translations. With a ?lang=en users would be able to override the language header provided by the browser.