Set explicit uri and base on NonRelativeURI type

[matentzn]

Fixes shaclgen "No URI for type" and sqltablegen "Unknown range base" errors. Workaround for LinkML generators not traversing typeof.

Workaround for linkml/linkml#3491.

make all produced a clean build but two streams of generator errors. Both stem from the same upstream LinkML behaviour: gen-shacl and gen-sqltable do not walk typeof to resolve type attributes. The fix is to redeclare on NonRelativeURI what it would otherwise inherit from its parent uri type.

Changes

Two attributes added to the NonRelativeURI type definition in src/sssom_schema/schema/sssom_schema.yaml:

NonRelativeURI:
  typeof: uri
  base: URI            # added
  uri: xsd:anyURI      # added
  description: ...

1. uri: xsd:anyURI — silences gen-shacl

Without this, shaclgen emits:

ERROR:linkml.generators.shaclgen:No URI for type NonRelativeURI

once per slot whose range is NonRelativeURI (15 occurrences). The SHACL generator reads the type's uri directly to populate sh:datatype and does not fall back to the parent type. xsd:anyURI is the URI declared on the LinkML built-in uri type — semantically a NonRelativeURI is an xsd:anyURI with an extra (prose-only) restriction, so this is the correct value rather than a minted sssom:NonRelativeURI (which no SHACL processor would understand).

2. base: URI — silences gen-sqltable

Without this, sqltablegen emits:

ERROR:linkml.generators.sqltablegen:Unknown range base: None for mapping_set_id = NonRelativeURI
ERROR:linkml.generators.sqltablegen:Unknown range base: None for license = NonRelativeURI
... (one error per slot referencing NonRelativeURI)

The SQL generator uses base to pick a SQL column type and, like shaclgen, doesn't traverse typeof. URI matches the parent type's base.

This is a workaround

The real bug is upstream: typeof is documented as inheritance, but SchemaView.get_type() returns child types as-declared and individual generators reimplement (or skip) the walk. Other generators in the same build (gen-python, gen-jsonld, gen-jsonschema, gen-graphql, gen-shex) handle the same schema fine, which makes the inconsistency a generator-side problem rather than a schema-author responsibility. Filed upstream — see linkml/linkml#3491.

Until that lands, redeclaring inherited attributes on every custom type is the established LinkML convention (cf. EntityReference in the same file, which sets base: str and uri: rdfs:Resource for the same reason).

Verification

make all -B after the change: no shaclgen or sqltablegen errors. Remaining output is GraphQL warnings about enum values like 1:1, n:n and imported class names like owl class (other problem)

• docs/ have been added/updated if necessary
• make test has been run locally
• tests have been added/updated (if applicable)
• CHANGELOG.md has been updated.

If you are proposing a change to the SSSOM metadata model, you must

• provide a full, working and valid example in examples/
• provide a link to the related GitHub issue in the see_also field of the linkml model
• provide a link to a valid example in the see_also field of the linkml model
• update the "Model changes across versions" (in src/docs/spec-models.md) accordingly
• run SSSOM-Py test suite against the updated model

[gouttegd]

Thanks for the detailed explanations.

I cannot test right now, but this looks good to me.

I would feel better if you could test the change against SSSOM-Py (as explained here), though. I understand that the change should not affect the Python generator (which was already doing the correct thing) and therefore should not affect SSSOM-Py, but well, we have a test suite, better use it.

[matentzn]

Tested against SSSOM-Py per CONTRIBUTING.md — full suite passes.

$ uv pip install /path/to/local/sssom    # the patched schema
$ uv run --all-extras pytest
============== 110 passed, 2 skipped, 249 warnings in 66.30s ==============

As expected — the change only affects shaclgen/sqltablegen output, neither of which SSSOM-Py consumes — but agreed, better to confirm.