One approach is to update the forward dictionary to make the IRIs onto one of the existing IVs and then rewrite all of the statements. However, this sort of destructive rewrite of does not help if you need the "redirects" to be reversible.

I am pretty sure that we only support this through eager materialization of the owl:sameAs inferences. While there is some code to dynamically expand access paths (BackchainAccessPath), I think that there are some issues with this code and it is disabled by default. See InferenceEngine.Options for the relevant options and comments.

It sounds like you have a use case where all you want is the ability to snap together two resources. That is, just the limited set of sameAs entailments. Do you know if this would include only same-as for instances or also for properties and classes?

if you need the "redirects" to be reversible.

I don't think redirect is reversible, but that's a good point, need to verify that. Technically it can be reversed, as pretty much every action on wiki, but I'm not sure if it's a normal occurrence. Will check.

Do you know if this would include only same-as for instances or also for properties and classes?

Probably just for regular nodes (instances) right now. Not sure about properties - I'm pretty sure it's not allowed in wikidata (instead, properties are just obsoleted and new ones are added). Will verify.

Do you know if this would include only same-as for instances or also for properties and classes?

Currently, property redirects are not allowed, though it may happen in the future, at least in theory.

@Smalyshev mentioned that Blazegraph has a rewrite mechanism we could use to resolve redirects when processing updates and queries. That works when we know that A redirects to B (we have <A> owl:same <B>). Problems arise when a redirect is created or undone, that is, when <A> owl:same <B> is added or removed from the database:

When <A> owl:same <B> is added, we have to replace all occurrences of <A> in the graph with <B> (and delete triples with <A> as the subject, since A's old content is now gone):

?s  ?p  <A>   becomes   ?s  ?p  <B>
?s  <A>  ?o   becomes   ?s  <B>  ?o
<A>  ?p  ?o   is deleted

But when <A> owl:same <B> is removed, we'd have to revert only some occurrences of <B> back to <A>, namely the ones that still reference A in the primary dataset on Wikidata. We'd need a way to find these.

Maybe named graphs could be used to solve this? When replacing <A> with <B>, we'd copy the original triple to a secondary graph <R> (R for "redirect"; and let's call the default graph <Q> for "query"):

?s  ?p  <A>  <Q>   becomes   ?s  ?p  <B>  <Q>   and   ?s  ?p  <A>  <R> 
?s  <A>  ?o  <Q>   becomes   ?s  <B>  ?o  <Q>   and   ?s  <A>  ?o  <R>
<A>  ?p  ?o  <Q>   is deleted

We can then undo a redirect by copying the redirects backed up in the <R> graph back into the <Q> graph.

All this has to be done for all URIs derived from the redirected entity ID, not just the concept URI.

we have to replace all occurrences of <A> in the graph with <B> (and delete triples with <A> as the subject, since A's old content is now gone)

Deletion happens automatically as part of the update, since new data only has one triple with A as a subject. However, replacement is harder. If we would replace all triples that mention <A> as an object, it can be an expensive operation.

But when <A> owl:same <B> is removed, we'd have to revert only some occurrences of <B> back to <A>

That would be pretty hard to do, given that the data may have changed - i.e., even if we kept the backup of the pre-redirect data, some of it may not be relevant anymore, as the corresponding subjects may have been updated by the user.

All this has to be done for all URIs derived from the redirected entity ID, not just the concept URI.

What other URIs are there?

In T96490#1225281, @Smalyshev wrote:

we have to replace all occurrences of <A> in the graph with <B> (and delete triples with <A> as the subject, since A's old content is now gone)

Deletion happens automatically as part of the update, since new data only has one triple with A as a subject. However, replacement is harder. If we would replace all triples that mention <A> as an object, it can be an expensive operation.

Yes, but it would be done only once per redirect, and even that should be rare.

Do you see an alternative that would be less expensive?

But when <A> owl:same <B> is removed, we'd have to revert only some occurrences of <B> back to <A>

That would be pretty hard to do, given that the data may have changed - i.e., even if we kept the backup of the pre-redirect data, some of it may not be relevant anymore, as the corresponding subjects may have been updated by the user.

You would have seen these modifications, and tracked them. Of course, if we have <X> <P> <B> <Q> and <X> <P> <A> <R>, an edit that changes X to have P:C instead of P:A would need to remove both <X> <P> <B> <Q> and <X> <P> <A> <R> before inserting <X> <P> <C> <Q>. You'd apply the update to the "backup" graph <R> without rewriting A to B, and the update of the "query" graph <Q> after rewriting A to B. Seems straight forward to me.

All this has to be done for all URIs derived from the redirected entity ID, not just the concept URI.

What other URIs are there?

As far as I can tell, there are currently no extra URIs for Items, but several variants of Property URIs (/prop/, /prop/statement/, /prop/statement/value/, etc). We currently don't have redirects for properties, but the fact that more than one URI may be derived from a given entity ID is something to keep in mind.

Yes, but it would be done only once per redirect, and even that should be rare

True, once per redirect, but redirects are not that rare... It may be an option though. We need to consider performance impact for this carefully.

As far as I can tell, there are currently no extra URIs for Items, but several variants of Property

I'd really hate redirecting properties, there's so much potential mess in it. Couldn't we just ban redirecting properties and if you really need it leave it to bots and community to clean up the data?

Seeing as we've run for a while with only owl:sameAs implemented and got no complaints, I don't think priority of "High" is warranted. We still want to get to it, but other things for which we do have an idea how to proceed will have to come first.