In examples, avoid HTTPS URIs that are not dereferenced during dereferencing

[kaefer3000]

Examples such as Example 3 contain URIs that contain a path that is actually not sent during dereferencing. As dereferencing is at the core of the definitions around controlling a document, such URIs could better be avoided, to at least avoid confusion and to avoid problems with relative URI reference resolution.

Consider Example 3:

Example 3: Usage of the id property

{
  "@context": "https://www.w3.org/ns/cid/v1",
  "id": "https://controller.example",
  "authentication": [{
      "id": "https://controller.example#authn-key-123",
      "type": "Multikey",
      "controller": "https://controller.example",
      "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }]
}

Here we have two URIs, https://controller.example and https://controller.example#authn-key-123 with an empty path component.

Now consider RFC9112, which says Sec. 3.2.1. in RFC9112 about a request other than OPTIONS or CONNECT, i.e. about dereferencing using GET:

If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target.

Also consider RFC3986, which says Sec. 5.1.3 in RFC3986 about the base URI against which relative references are to be resolved:

If no base URI is embedded and the representation is not encapsulated
within some other entity, then, if a URI was used to retrieve the
representation, that URI shall be considered the base URI. Note that
if the retrieval was the result of a redirected request, the last URI
used (i.e., the URI that resulted in the actual retrieval of the
representation) is the base URI.

Then you get a problem with relative reference resolution, e.g. if the above JSON can be retrieved from https://controller.example/, a relative URI, say #authn-key-123 to stick with the example, cannot be resolved to https://controller.example#authn-key-123.