---
id: ch10-spatial
type: spine
title: "Metadata as infrastructure: from hard-coded functions to Raven"
readingTime: 3
standalone: true
core: false
teaser: "The first GeoAI demos needed one Python function per dataset. The Beta lets metadata decide which data and tools to use, so metadata quality now matters a great deal."
voice: thinker
parent: null
diagram: fig-metadata-stack
recallQ: "What changed between the PoliRural+ proof of concept and the Beta in how data reaches the AI tools?"
recallA: "The proof of concept hard-coded Python functions for fixed datasets, with metadata hidden in code comments. The Beta relies on explicit metadata and service descriptions, so Raven can select datasets and set up generic tools over them, which makes metadata quality decisive."
highlights:
  - "Proof of concept: hard-coded functions; Beta: generic tools set up over described data"
  - "Raven resolves data references and tool contexts for JackDaw"
  - "Standards stack: ISO 19115/19119, Micka, Layman, STAC, OGC API – Records, RO-Crate, I-ADOPT"
  - "Pilots must describe coverage, validity, licences and known limitations"
status: accepted
concept: spatial-data-infrastructure
conceptTitle: "Metadata-driven spatial data infrastructure"
parents: jackdaw
lang: en
lens: generic
depth: standard..technical
formalism: none
visuality: balanced
lengthBand: standard
genre: explainer
state: edited
carriers: prose|table|diagram
---

The early proof-of-concept demonstrations ran chat flows on **hard-coded Python functions**, with metadata often tucked into code comments. That was enough to prove the interaction logic, but not to reuse or scale. The second release puts the weight on **explicit, higher-quality metadata**. This lets the platform move from fixed tool-and-data pairs to generic tools that can run over many datasets (D4.2 §3.2).

## Raven

**Raven** selects the relevant data resources and sets up tools on top of them as needed. Its inputs are catalogue metadata, service descriptions, dataset identifiers, access URLs, spatial descriptors and repository information. Its outputs are discoverable records, publishable services, resolved data references and tool contexts that [JackDaw](#c/jackdaw) can use (§3.2). In the pilots, Raven let teams register local datasets, state their spatial and temporal validity, and make them available to other tools **without manual code changes** (§6.3). For the final release, Raven's metadata should also drive tool selection, access control, provenance tracking and checks of whether a dataset suits a task (§11.1).

## The standards stack

| Layer | Standard or tool | Source |
|---|---|---|
| Geographic metadata | ISO 19115 (data), ISO 19119 (services) | D4.1 §6.5 |
| Catalogue and harvesting | Micka: INSPIRE metadata, harvesting via CSW and WMS | D1.1 §3.2 |
| Layer publishing | Layman: WMS and WFS, access control | D1.1 §3.2 |
| Spatio-temporal discovery | STAC, OGC API – Records (from FOCAL) | D4.2 §9.1 |
| Packaging and semantics | RO-Crate with JSON-LD; I-ADOPT variables (from FAIR2Adapt) | D4.2 §9.4 |

## What pilots have to provide

D4.2's first corrective action is better guidance for preparing pilot data. It covers **metadata completeness, spatial coverage, temporal coverage, licences and known limitations** (§6.4). Without these, the same tool behaves unevenly from one dataset to the next.

## Why this is a research result

D4.2 concludes that metadata "has become a core operational element of the platform". It supports interpretation, tool selection, access management, provenance and AI-assisted workflows, not only catalogue search. Its quality "directly affects the reliability of downstream services", JackDaw included (§12). The open data layers this applies to, such as [Copernicus](#c/copernicus-data), are covered in chapter 4.

**Sources:**
- D4.2 PoliRuralPlus Platform Beta, §3.2 Data and metadata services; §6.3; §6.4; §9.1 FOCAL; §9.4 FAIR2Adapt; §11.1; §12 Conclusions. [PDF](https://www.poliruralplus.eu/docs/421/D4.2_PoliRuralPlus_Platform_Beta.pdf)
- D4.1 PoliRuralPlus platform design, §6.5 Magpie. [PDF](https://www.poliruralplus.eu/docs/162/D4.1_PoliRuralPlus_platform_design_v1.pdf)
- D1.1 Project Web Pages Update, §3.2 Map management. [PDF](https://www.poliruralplus.eu/docs/139/Attachment_0_53.pdf)