w3c
Is it graph merge or graph equivalence?
There is a note in the definition of equivalentId, which says:
equivalentId is a much stronger form of equivalence than alsoKnownAs because the equivalence MUST be guaranteed by the governing DID method. equivalentId represents a full graph merge because the same DID document describes both the equivalentId DID and the id property DID.
It is not clear to me what "graph merge" means in this note. Don't we talks about "graph equivalence" of some form here? Or, to use the RDF terminology, is this relationship the same owl:sameAs ?
(Note that the same terminology is used for the canonical ID; if the WG agrees to change the terminology, it must be done in both notes.)
Hmm I think you're right that "graph equivalence" is a more appropriate term than "graph merge". The idea is that when you resolve DID A you get back exactly the same DID document as when you resolve DID B, except that the "id"s are different (A or B, respectively).
I don't think it's quite the same as owl:sameAs, since (as I understand) owl:sameAs doesn't guarantee the same behavior as I described above. Maybe equivalentId and canonicalId can be considered subproperties of owl:sameAs ?
sameAs means that for every triple that contains the term "A", the same triple, but with "A" replaced by "B", is also true. And vice versa (i.e., the relationship is reflexive). This seems to reflect what we want for equivalentId. Whether we declare it as a subproperty of owl:sameAs, or simply reproduce the definition, is an editorial issue. I would prefer not to refer to owl:sameAs in the spec text, but rather refer to graph equivalence the way you said. (We can do a subproperty definition once we get down to the formal specification of the terms. That is a separate issue, however.)
Actually, thinking about it further, declaring the property as a subproperty of sameAs may not be entirely o.k. sameAs is a universal statement about those two resources, whereas what we are looking for is a sameAs behaviour in the context of DIs. I do not think it is appropriate to make a statement about these resources outside that context.
So I things defining things in terms of equivalent graphs with that pair of resource interchanged is the proper way to go. In any case, there is no merge imho.
This was discussed during the #did meeting on 19 June 2025.
View the transcript
Is it graph merge or graph equivalence? #115
<ottomorac> w3c/
ottomorac: This related to the equivalentID term: https://
merge".
<Zakim> JoeAndrieu, you wanted to say this is a place where the properties in the DID document are not about the subject, but about the DID
JoeAndrieu: this depends on whether you read the JSON as JSONLD or not you have different interpretation
… I don't think anyone meant that "same as" means you should do a graph merge
… This is a statement that is much more about the subject. It is like having two different VCs about the subject. Whether you choose to trust those and merge them in your data set depends
… We should not do a merge in a way that is proposed here
markus_sabadello: I think at least a part of this issue is obsolete
… DID resolution results should be JSON and not JSONLD
… One of the discussion points was whether equivilantId should be the same as "same as". It is no longer an rdf property
… I don't know if we need to say anything about this
… We are saying something about equivalentId and what it means
… Each equivalentId value is logically equivalent to the id property and refers to the same subject
ottomorac: Wondering about the history of this green box clarification
<Zakim> JoeAndrieu, you wanted to mention security
JoeAndrieu: I think it was meant to be a report by the resolver for another way you can get to the same thing
… If we think about equivalentId as giving this intention that you are supposed to merge the graph in the DID document.
… This is back to the pattern where you are supposed to merge the controllers. All verification methods in both documents should be considered as proofs of either DIDs. We need to clarify that that is not what is meant here
… We need to be clear that from a security standpoint you do not want to merge the two sets of verificationRelationships
markus_sabadello: I remember why we have this. There were DID methods with multiple forms of a DID. The idea was always that you get back the same DID document for these two identifiers acccept that the identifer is in a different form
… From that perspective also a graph merge doesnt really make sense
… It is the same graph. Maybe it is more of a graph equivalence
… Again not sure if there is spec text that should be added
ivan: The important point from Markus is that equivalence means I get back exactly the same DID document
… There is no issue about graph merge
… There is this example about using lowercase and uppercase in the DID URL
… All the rest is confusing things
… From the DID resolver point of view, these two identifiers lead to the same DID document.
ottomorac: So we just simplify things.
ivan: The RDF point is moot, as we are not using RDF in DID resolution
ottomorac: Sounds like we have a proposal to simplify the language to make this point of the equivalence
ottomorac: Need someone to write a PR, but at least we have direction
AlsoKnownAs. AKA. Alias. Weaker than owl:sameAs.
Dereferencing each AKA URL can result in a different descriptions — but they are all, nonetheless, descriptions of the same Entity.
That's the way I understand it....
And it does suggest that a graph merge might result in a clearer overall description — or the merge might confuse things entirely.
Five blind people encounter an elephant. One each encounters the tail, the trunk, a leg, an ear, or the body. Each describes the part they encountered, and no description from one matches the description from any other. But All Are Correct! A graph merge of these descriptions would be gibberish.
I hope this helps to clarify this puzzle.
equivalentId is not about seeing different parts of the elephant. It's about having two different names for the elephant that looks the same no matter which name you use.
Looking at the current spec text here: https://www.w3.org/TR/did-resolution/#dfn-equivalentid
How about changing this language:
equivalentId represents a full graph merge because the same DID document describes both the equivalentId DID and the id property DID.
To this:
equivalentId represents graph equivalence because the same DID document describes both the equivalentId DID and the id property DID.
Would this address this issue? Any other suggestions?
As I said on the call: because we decided we do not use RDF in resolutions, it does not really make sense to bring graph terminology into this spec. No reason to refer to graph equivalence in the first place.
equivalentID means that the resolver will return the same DID document. That is it... imho
I created PR https://github.com/w3c/did-resolution/pull/158 to avoid the terms "graph merge" or "graph equivalence".
Addressed by https://github.com/w3c/did-resolution/pull/158, marking pending-close.