Setting up a user dependent namespace document

[iherman]

The latest version of the @context file includes a reference, via a @vocab, to the https://www.w3.org/ns/credentials/issuer-dependent URL. At present, this URL leads to a 404, which is a big no-no. This PR creates a short "namespace document" alongside the VCDM vocabulary at https://github.com/w3c/vc-data-model/tree/main/vocab/credentials/v2/issuer-dependent.html (the file can be previewed here) which provides a simple landing place.

Although not part, physically, of the PR, I also have on my local disc a .htaccess file that is ready to be pushed onto https://www.w3.org/ns/credentials/ and which looks as follows:

RewriteEngine On
RewriteBase /ns/credentials/
AddType application/ld+json .jsonld
AddType text/turtle .ttl


RewriteRule ^v2$ https://w3c.github.io/vc-data-model/contexts/credentials/v2 [E=json,P]
RewriteRule ^issuer-dependent$ https://w3c.github.io/vc-data-model/vocab/credentials/v2/issuer-dependent.html [P]

which takes care of mapping the @vocab URL to the file set up by this PR and, incidentally, also makes the mapping of the latest context file from /ns/, as requested in #935 (and as requested by @OR13). Note that the .htaccess filed does not map the core vocabulary file from https://www.w3.org/ns/credentials/, because that is still a pending issue #758. If the decision in #758 is to make that change, then the aforementioned .htaccess file can be extended accordingly.

[iherman]

Note, b.t.w., that the VDCM specification has an outdated context file in the appendix, which does not seem to include the @vocab entry. This PR does not touch that file.

[OR13]

Thank you!

[TallTed]

Minor tweaks.

[msporny]

LGTM, might need a tiny bit of editorial cleanup after the merge, but that would be ... editorial... no need to do that here, in the first PR.

[melvincarvalho]

Normally in Linked Data a term in a vocab will dereference so that it's possible to learn more about the term, for example the type of the item (string, number, date etc.) the human readable label and so on

Looking at this vocab, that seems not to be the case here wrt dereferening

If the term will not dereference would it not be better to remove the centralized http dependency, and extra round trip by using a URN?

RFC 8141 provides for a documentation to be given for URNs without requiring the round trips that many libraries (e.g. solidOS) will fire off automatically.

It would be good to understand this pattern from a Linked Data point of view.

If the aim is to provide a placeholder for json terms that are not registered, then there could be more benefit from a general solution that many systems could use, solving the problem of uniftying JSON and JSON-LD once and for all

[iherman]

Normally in Linked Data a term in a vocab will dereference so that it's possible to learn more about the term, for example the type of the item (string, number, date etc.) the human readable label and so on

Looking at this vocab, that seems not to be the case here wrt dereferening

If the term will not dereference would it not be better to remove the centralized http dependency, and extra round trip by using a URN?

RFC 8141 provides for a documentation to be given for URNs without requiring the round trips that many libraries (e.g. solidOS) will fire off automatically.

It would be good to understand this pattern from a Linked Data point of view.

If the aim is to provide a placeholder for json terms that are not registered, then there could be more benefit from a general solution that many systems could use, solving the problem of uniftying JSON and JSON-LD once and for all

I find the argument of using a URN for this case compelling. This should probably be raised as a separate issue.

@OR13 @msporny ?

[OR13]

@iherman I think we can create a better experience for users by retaining URL structure.

I don't think using URNs for this case would be an improvement.

[iherman]

Just for the sake of arguments: we are talking about users who do not care about URL-s, Linked Data, etc; this is a fallback for that community. Which is fine, but then I do not understand your point. They would not care about the format of the identifier, whether it would start with a https or a urn...

[OR13]

@iherman I think the intention is to provide term definitions that gently encourage issuer's to do a better job at linked data... These users are not intending to ignore linked data, let us not assume why they have failed to define terms in the context.

Making the term's URNs seems like the opposite of helping or educating.

Providing a web page that gives gentle guidance and instruction is better than spitting out unresolvable URNs, because the latter provides no guidance or instruction... no incentive for improvement and therefor it is likely to encourage even lower quality linked data.

[melvincarvalho]

Thanks @iherman I guess it does warrant its own issue. I'll just reply with some added information.

RFC 8141 provides a means for documentation, namely

https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

On the topic a general solution to this problem. Might it perhaps be useful to register urn:jsonld with IANA?

Edit: moved to new issue

[msporny]

Editorial, multiple reviews, changes requested (some applied, one tracked in a new issue), no objections, merging.

[iherman]

For the records: the .htaccess file has been installed; these two URL-s should work now as required:

• https://www.w3.org/ns/credentials/v2
• https://www.w3.org/ns/credentials/issuer-dependent

cc @msporny @OR13

[OR13]

Awesome!