Sibling of #389 (array-context) and #390 (@type: '@json'). Surfaced when checking whether test.solid.social's JSON-LD profile and its conneg-converted Turtle form match.

Symptom

When a JSON-LD profile contains a predicate whose values are inline objects (rather than flat IRI references), the conneg-emitted Turtle drops:

1. The predicate triple connecting the subject to the inline objects
2. The inline objects' own triples (their @id, @type, attributes)

The authentication predicate survives because it points at a flat IRI. The verificationMethod predicate disappears because its values are full inline-object descriptions.

Reproduction

The on-disk profile at test.solid.social/profile/card.jsonld contains:

{
  "@context": { "...": "...", "verificationMethod": { "@id": "cid:verificationMethod", "@container": "@set" }, "publicKeyMultibase": { "@id": "cid:publicKeyMultibase" }, ... },
  "@id": "https://test.solid.social/profile/card.jsonld#me",
  "verificationMethod": [{
    "id": ".../card.jsonld#nostr-key-1",
    "type": "Multikey",
    "controller": ".../card.jsonld#me",
    "publicKeyMultibase": "fe70102de7ec..."
  }],
  "authentication": [".../card.jsonld#nostr-key-1"]
}

Asking JSS for Turtle:

curl -H 'Accept: text/turtle' https://test.solid.social/profile/card.jsonld

returns (excerpt):

<https://test.solid.social/profile/card.jsonld#me> a foaf:Person, schema:Person;
    ...
    <https://www.w3.org/ns/cid/v1#controller> <.../card.jsonld#me>;
    <https://www.w3.org/ns/cid/v1#service> <.../card.jsonld#oidc>;
    <https://www.w3.org/ns/cid/v1#authentication> <.../card.jsonld#nostr-key-1>.
<https://test.solid.social/profile/card.jsonld#oidc> a <https://www.w3.org/ns/lws#OpenIdProvider>;
    <https://www.w3.org/ns/cid/v1#serviceEndpoint> <https://solid.social/>.

Note:

• ❌ No cid:verificationMethod predicate on #me at all
• ❌ No description of #nostr-key-1 (no a Multikey, no controller, no publicKeyMultibase)
• ✅ cid:authentication <.../card.jsonld#nostr-key-1> survives (flat IRI)
• ✅ cid:service <.../card.jsonld#oidc> survives, AND the #oidc resource IS described (because it's referenced as a flat IRI from the subject AND its description is at the top level of the doc, not nested inside service)

So the rule seems to be: predicates whose values are inline objects (vs. flat IRI references with the resource described at the document root) get dropped.

Why this matters

• JSS's own backend works because the resource-side LWS10-CID verifier (src/auth/nostr.js / src/auth/cid-doc-fetch.js) requests application/ld+json. The CID-VM check path is unaffected.
• Third-party Turtle consumers see a profile with cid:authentication <#nostr-key-1> but ZERO triples about #nostr-key-1. They can't find the key material — RDF-store integrations, SPARQL endpoints, CID validators that prefer Turtle, generic Solid clients that default to text/turtle.
• This is the "JSON-LD and Turtle profiles match" property that Profile-to-key linking aligned with LWS 1.0 (FPWDs 2026-04-23) via W3C Controlled Identifiers v1.0 #386 / profile: emit CID v1 controller + prep verificationMethod context (#386 Phase A) #388 (LWS 1.0 alignment) implicitly relies on. Right now they don't match for any pod with a Nostr/Schnorr verificationMethod.

Likely root cause

src/rdf/turtle.js's emitter probably walks the JSON-LD object's top-level keys and emits a triple per predicate-value pair, but doesn't recursively descend into inline-object values to:

1. Emit the predicate referencing the inline object's @id
2. Recursively emit the inline object's own triples

Compare to how service works (and survives): the JSON-LD likely has service: [".../card.jsonld#oidc"] as a flat-IRI list AND a top-level #oidc block describing the service endpoint. Two parallel descriptions. The Multikey VM is only declared as an inline object inside verificationMethod — there's no top-level #nostr-key-1 block to fall back to.

Possible fixes

A. Hoist + flatten on serialize: when emitting Turtle, replace inline objects with flat IRI references AND emit a top-level resource block per inline object. This is the standard JSON-LD → flat-N-Quads transformation.

B. Recursive emission: walk inline-object values, emit them as anonymous (or named, if @id present) resource blocks alongside the parent.

C. Switch to a real JSON-LD library: jsonld.js (digitalbazaar) handles this correctly out of the box. JSS's deliberate choice to avoid remote-context fetches (#389) is preserved by passing a pre-resolved local context map.

(C) is the most robust but biggest change. (A) or (B) would unblock the immediate use case.

Acceptance test

After the fix, the Turtle conversion of the test profile must contain:

<.../card.jsonld#me>
    cid:verificationMethod <.../card.jsonld#nostr-key-1>;
    cid:authentication <.../card.jsonld#nostr-key-1>.

<.../card.jsonld#nostr-key-1>
    a cid:Multikey;
    cid:controller <.../card.jsonld#me>;
    cid:publicKeyMultibase "fe70102de7ec...".

(Whitespace + prefix-vs-IRI formatting may vary; the triple set must match.)

Refs

• Profile-to-key linking aligned with LWS 1.0 (FPWDs 2026-04-23) via W3C Controlled Identifiers v1.0 #386 / profile: emit CID v1 controller + prep verificationMethod context (#386 Phase A) #388 — LWS 1.0 + W3C CID v1 alignment (the work that put this VM into the profile)
• rdf/turtle: JSON-LD @context array form not handled — locally-resolvable contexts only #389 — sibling Turtle bug (array-context loses term expansion)
• rdf/turtle: emit @type:'@json' literal values (rdf:JSON datatype) — Phase B blocker for CID publicKeyJwk #390 — sibling Turtle bug (@type: '@json' literals not emitted — relevant when VMs use publicKeyJwk instead of publicKeyMultibase)
• auth: serve /.well-known/did/nostr/<pubkey>.json (#407) #408 — well-known did:nostr endpoint (uses the same VM data, but reads JSON-LD only)