Using `@base` with a DID causes truncation of prefix in the playground (after the first colon?)
Opened this issue · 2 comments
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.
<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.
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.)