Is it graph merge or graph equivalence?

[iherman]

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.)

[peacekeeper]

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 ?

[iherman]

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.)

[iherman]

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.