Build a property URI a field name cannot break, and say why SEEK refused

[sorenwacker]

Provisioning a profile to a live SEEK 1.18.1 failed with:

Errors: Sample Type cropxr-metabolomics Source: Client error '422 Unprocessable Content'
for url 'http://localhost:3000/sample_types'

The bug

One field is named Source Name. pid=f"{_PID_BASE}{field.name}" made that http://schema.org/Source Name, and SEEK validates the pid: it rejected the entire Sample Type over one attribute, naming none of them. rdflib was equally unhappy on the other side, warning the same URI "does not look like a valid URI, trying to serialize this will break".

Both sides now derive the URI through one helper, metaseed.seek.naming.property_uri, which percent-encodes the local name. It has to be one helper rather than two fixes: SEEK matches an FDS-imported sample to its Sample Type attribute by this URI, so provisioning and the data RDF must produce byte-identical values or an import silently matches nothing. A name that needs no encoding is returned unchanged, so every URI already registered in a SEEK instance stays where it is — nothing to migrate.

Why it took a live instance to find

The error surfaced to the user was httpx's bare status line plus a link to MDN. SEEK answers a rejected write with a JSON:API errors array naming the offending attribute, and we discarded it. SeekApiError now parses and raises it:

SEEK rejected POST /sample_types (422): {'sample_attributes.pid': ['not a valid URI']}

That one line identified the bug immediately, after four blind attempts. Every SEEK failure was previously unactionable in the same way.

Verified

Against the reporter's SEEK 1.18.1 after the fix: created: ['Sample Type: cropxr-metabolomics Source'], no errors, Sample Type id 21.

58 SEEK tests pass, four new: the space is encoded, an ordinary name is untouched, every planned pid parses as an absolute URI, and the data RDF emits the same URI provisioning registers.