It has happened on one occasion that instead of the short 18-byte hashsum (24 base64url symbols) a full 32-byte hashsum has been inserted into the magic SPARQL index, despite the RDF containing the correct, short canonical URL. The problematic object was https://citymeta.icos-cp.eu/objects/85gAphoBMohKzGCH-O_4I6UW , and the symptom was that a full-hashsum-based URL https://citymeta.icos-cp.eu/objects/85gAphoBMohKzGCH-O_4I6UWYhoEyEFkLtXGWpytHNA was coming out of the "magic" SPARQL queries listing the data objects. The problem was solved by re-indexing, but we should consider how this could have happened, and take some measures against this happening again.
It has happened on one occasion that instead of the short 18-byte hashsum (24 base64url symbols) a full 32-byte hashsum has been inserted into the magic SPARQL index, despite the RDF containing the correct, short canonical URL. The problematic object was https://citymeta.icos-cp.eu/objects/85gAphoBMohKzGCH-O_4I6UW , and the symptom was that a full-hashsum-based URL https://citymeta.icos-cp.eu/objects/85gAphoBMohKzGCH-O_4I6UWYhoEyEFkLtXGWpytHNA was coming out of the "magic" SPARQL queries listing the data objects. The problem was solved by re-indexing, but we should consider how this could have happened, and take some measures against this happening again.