Register panes against urn:solid types as the canonical surface

[melvincarvalho]

Background

LOSOS selects panes by @type. Each pane module declares which type(s) it renders, and the pane store routes incoming linked-data objects to the matching pane.

The problem with using upstream IRIs as the registration key is that real Solid pods are vocabulary-heterogeneous. The same conceptual thing — a Person — appears in pod data as foaf:Person, schema:Person, vcard:Individual, or just bare Person from a LION document. A pane registered against foaf:Person doesn't fire when the data uses schema:Person. Pane authors end up either enumerating every variant or writing duplicate panes.

Proposal

Panes SHOULD register against urn:solid: types as the canonical surface, with the LOSOS runtime mapping incoming @type values to their urn:solid equivalent before dispatch.

Concretely:

• A "Person" pane registers against urn:solid:Person.
• Incoming data with @type: foaf:Person, @type: schema:Person, or bare @type: Person (which expands to urn:solid:Person per the LION RDF Compatibility recommendation) all match.
• The mapping is driven by the urn:solid registry — every term carries an owl:sameAs to its canonical upstream IRI, which the runtime can index in reverse to resolve incoming types.

Why this works for LOSOS specifically

1. Pods are vocab-mixed. Data from many apps lands in one pod, each app picking its own vocabulary. Without an indirection layer, pane authors must enumerate. With urn:solid, they don't.
2. Stable across sync clients. WebSocket-synced clients all need to agree on which pane handles which type. urn:solid types are stable in a way that per-app or per-vocab contexts aren't.
3. Already on the stack. LOSOS includes LION (~1.5 KB of the 6 KB total). The merged LION change (linkedobjects/linkedobjects#6) makes urn:solid the recommended default vocab for RDF compatibility — LOSOS inherits the recommendation for free.
4. Pane authors write once, match everywhere. A urn:solid:Person pane handles every Person variant a pod can throw at it.

Open questions for design

1. Where does the @type → urn:solid: mapping live? Options:
   • Bundled snapshot of the registry (small, fast, ages)
   • On-demand fetch from https://urn-solid.github.io/index.json (always fresh, network dependency)
   • Both — bundle a snapshot, refresh in the background
2. Pane registration syntax: keep current API and let panes register against either upstream IRIs or urn:solid types (with urn:solid recommended), or migrate fully?
3. Subspaced urn:solid identifiers (urn:solid:agent:…, urn:solid:msg:…) don't fit LOSOS's URL-as-data-source model — confirm we scope this to vocabulary terms only (bare form).

Related

• LION RDF Compatibility section: Add RDF Compatibility section recommending urn:solid as default vocab linkedobjects.github.io#6 (merged)
• urn:solid namespace spec: https://urn-solid.github.io/spec/
• urn:solid registry (~440 terms): https://urn-solid.github.io/

Concrete next steps (if accepted)

1. Decide registration API direction (additive vs migration).
2. Bundle or fetch the urn:solid index.
3. Update the pane-development docs/examples to register against urn:solid: types.
4. Add a section to the LOSOS README spelling out the pane-by-urn:solid-type pattern.