<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi, thank you for interesting QGIS server and metadata discussion, I have a couple of thoughts to add:<div class="">- Related to FGDC support, since QGIS manages metadata in a local model, the capability is requested to import from and export to FGDC metadata, and potentially extend the local model to support important fields of FGDC. In our bridge product we foresee capabilities to import/export to iso19139 metadata, but would be interesting to also see FGDC support (see <a href="https://github.com/GeoCat/qgis-bridge-plugin/issues/6" class="">https://github.com/GeoCat/qgis-bridge-plugin/issues/6</a>)</div><div class="">- A getcapabilities typically exposes metadata in 2 ways, a limited set of properties embedded in service and layer metadata in getcapabilities (contact, title, abstract, keywords) and for each layer a link to an external document having detailed metadata. For the first set it makes sense to use metadata stored in the QGIS project directly. For the second set this will be a bit harder, since the metadata stored in the project is not necessarily exposed externally as a document. QGIS server would need a catalogue capability to facilitate this use case. An alternative could be to ‘publish’ records in an external catalogue instance (pycsw/geonetwork), and store locally a reference to where the metadata for a layer is published. The bridge plugin already supports this use case as it publishes local records to an external catalog. A thing to consider is that metadata records exposed to the web typically require a common metadata model such as iso19115/FGDC, so the catalog component needs to have a capability to expose records in those models (or a transformation should be done while publishing the record).</div><div class="">I would love to hear how people envision these workflows and how they see the bridge plugin would be able to contribute.</div></body></html>