https://w3c.github.io/did-resolution/contexts/did-resolution-v1.json may not be correct

[iherman]

At present, the context file includes

didDocument: "https://www.w3.org/ns/did/v1"

That is incorrect; the URL is the context file's reference for DID v1, not the URL of the didDocument property.

What this shows is that, at some point, the vocabulary for the did resolution must be properly defined, as it was done for the various vocabularies in the VC spec family.

[peacekeeper]

I agree, there are some aspects of this context that need to be fixed/improved.

In this case of the didDocument property, I think my rationale was that yes, https://www.w3.org/ns/did/v1 is the URL of the DID v1 context file. But could it not simultaneously ALSO be the URL of the didDocument property?

In other words, wouldn't it be somewhat logical that the URL of a property equals the URL of a context file which defines the data model that is the value (range) of the property?

If this makes no sense from an RDF / Linked Data perspective, no problem, happy to change it :)

[iherman]

In this case of the didDocument property, I think my rationale was that yes, https://www.w3.org/ns/did/v1 is the URL of the DID v1 context file. But could it not simultaneously ALSO be the URL of the didDocument property?

One could argue that the RDF specification does not say anything, formally, about the Resource that is retrieved by the URI used to identify a resource, so this is not fully incorrect. But I believe it goes against Linked Data practice. When dereferencing a property's URL, one expects an RDF Schema entry definition of a term or, at the minimum, a human readable definition of the term. Not a JSON-LD context file, which is a totally different animal.

(See, for example, the controller term, whose identifier is https://w3id.org/security#controller, and which dereferences to an HTML+RDFa definition if HTML is requested, or Turtle equivalent if Turtle is requested.)

I believe the right thing to do is to say:

didDocument: "https://w3id.org/did-resolution#didDocument",

and, at some point, we should work on the formal vocabularies (including the DID Core vocabulary) to provide a proper definition for the term (and the others). Just repeat what we did for VC. Such vocabulary definition(s) would include a Class definition for DidDocument, subclass of sec:controlledIdentifierDocument, which would be the range for didDocument.

Whether we define one common vocabulary for DID Core and for Resolution, or whether we define two separate vocabularies, is up to the WG to decide. (E.g., in VC, we have three separate vocabularies (VCDM, Status list, and Data Integrity) and, for historical and deployment reasons, we put all the controlled identity terms into the Data Integrity vocabulary.)

CC @pchampin @msporny @dlongley

[msporny]

I agree with Ivan's take on the situation.

We also might want to question whether resolver results should be JSON-LD (and not just plain JSON). We might be creating more work than necessary for ourselves if we try to make resolver results themselves be JSON-LD.

[iherman]

We also might want to question whether resolver results should be JSON-LD (and not just plain JSON). We might be creating more work than necessary for ourselves if we try to make resolver results themselves be JSON-LD.

I am not really versed in the work on resolvers, so I did not want to say that... But I agree. When reading the spec, I was a bit surprised to see JSON-LD there.

Nevertheless, although not necessarily a concern for the resolution spec, we will have to clean up the vocabulary for DID Core.

[peacekeeper]

Marking as pending-close, since #135 has been merged and new issues w3c/did#884 and #137 have been created.