Using @base with a DID causes truncation of prefix in the playground (after the first colon?)

[trwnh]

In playing around with w3c/json-ld-syntax#446 (i.e. where @type is not an IRI), I discovered that the playground will take this:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    {"@base": "did:plc:ewvi7nxzyoun6zhxrhs64oiz"}
  ],
  "id": "did:plc:ewvi7nxzyoun6zhxrhs64oiz",
  "service": [
    {
      "id": "#atproto_pds",
      "serviceEndpoint": "https://enoki.us-east.host.bsky.network",
      "type": "AtprotoPersonalDataServer"
    }
  ]
}

and canonize it as this:

<did:plc:ewvi7nxzyoun6zhxrhs64oiz#atproto_pds> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <did:AtprotoPersonalDataServer> .
<did:plc:ewvi7nxzyoun6zhxrhs64oiz#atproto_pds> <https://www.w3.org/ns/did#serviceEndpoint> <https://enoki.us-east.host.bsky.network> .
<did:plc:ewvi7nxzyoun6zhxrhs64oiz> <https://www.w3.org/ns/did#service> <did:plc:ewvi7nxzyoun6zhxrhs64oiz#atproto_pds> .

Note that <did:AtprotoPersonalDataServer> is being emitted as the canonization of AtprotoPersonalDataServer which is incorrect.

Tangentially, taking out the @base from the @context and absolutizing the service.id in some other way (like prefixing it with a URI) will cause the processor to emit a warning about a "relative @type reference".

Also tangentially, taking out the @base from the @context and also taking out the # from the id atproto_pds will exhibit similar behavior -- <did:atproto_pds> is emitted as the object of the quad.

{"@base": "did:plc:ewvi7nxzyoun6zhxrhs64oiz"} will do this, but {"@base": "did:plc:ewvi7nxzyoun6zhxrhs64oiz#"} will also do the same thing.

In short, the playground is behaving as if I am declaring {"@base": "did:"}; the base IRI is seemingly truncated after the first colon.

[gkellogg]

<did:AtprotoPersonalDataServer> is correct, according the the way IRIs are resolved. Rules are different for resolving vocabulary-relative and document-relative IRIs, and @type uses both vocabulary- and document-relative processing (different from everything else). If it were vocabulary relative, and @vocab had been set to "did:plc:ewvi7nxzyoun6zhxrhs64oiz", "AtprotoPersonalDataServer" would get appended, yielding <did:AtprotoPersonalDataServerAtprotoPersonalDataServer > (probably also not what you'd want).

Given that it is document-relative, the rules for resolving relative IRIs ( "AtprotoPersonalDataServer") are defined in RFC3886 Relative Resolution. The operative bit in 5.2.3 Merge Paths is:

return a string consisting of the reference's path component
appended to all but the last segment of the base URI's path (i.e.,
excluding any characters after the right-most "/" in the base URI
path, or excluding the entire base URI path if it does not contain
any "/" characters).

The base URI has only one segment, so the relative IRI is appended to the scheme.

[trwnh]

Then it sounds like there is no way to correctly append a relative reference to even an explicitly provided @base.

So, to properly handle relative references to DIDs or DID URLs, is the error in:

• json-ld.org/playground ?
• jsonld.js ?
• w3c/json-ld-syntax ?
• RFC 3886 ?

I am inclined to believe there is an error in either the playground, the library powering the playground, or the JSON-LD spec itself. The relative IRI shouldn't be appended to the scheme, it should be appended to the authority. In fact, looking at RFC 3886 says exactly this:

If the base URI has a defined authority component and an empty path, then return a string consisting of "/" concatenated with the reference's path; otherwise,

So I would assume that at minimum, the library jsonld.js has a bug in it... would you agree? Should this bug be moved to jsonld.js, or is there spec language in JSON-LD that needs to be amended as well? (At a quick glance, I'm not finding any spec language, but I may be overlooking some.)