From: Sebastian T. <tr...@kd...> - 2009-12-10 11:08:23
|
Nathan wrote: > Sebastian Trueg wrote: >> Tim Haynes wrote: >>> Sebastian Trueg wrote: >>> >>>> Is there a query that would replace one URI with another one in all >>>> graphs? In other words: I need to "rename" one resource and make sure >>>> that all statements in all graphs are updated accordingly. >>>> Currently I am doing that on the client side which is rather slow. >>>> >>> Personally I'd consider: >>> >>> update rdf_quad >>> set >>> s=iri_to_id('http://some/new/thing') >>> where >>> s=iri_to_id('http://some/old/thing'); >>> >>> Adjust for ?p and ?o columns to taste. >>> >>> It touches on potentially many rows in the quad-store, but the iri_to_id() >>> calls can be optimized to happen only once each and the lookup will be fast >>> between hash-values. >>> >>> Beware of caching IRI lookups, however: the above might require a >>> server-restart to take effect. >>> >> I feared that SQL would be the solution. I would really prefer a SPARQL >> query. And a server restart is not possible anyway. So maybe I need to >> stick to my client-side solution. >> >> BTW: Is there any chance Virtuoso could get some additional SPARQL >> features? I am especially interested in more named graph support in >> SPARUL. Then maybe something like the following would be possible: >> >> "update graph ?g { <newuri> ?p ?o . } where { graph ?g { <olduri> ?p ?o >> . } }" >> >> Just an idea.... >> >> Thanks for your help. :) >> >> Cheers, >> Sebastian >> > > I'm assuming you're taking the approach of two sparuls, insert followed > by a delete? yes. > slightly off-topic; but why are you changing subject uri's? In KDE 4.3 and before that we used file:/ URLs as resource URIs for the resources representing the files in the RDF db. Thus, whenever a file was moved we needed to update all statements that referred to that file. Starting with KDE 4.4 we are using another approach with resource URIs that "never" change in combination with one url property. But I still need to convert the old data when I come across it. Cheers, Sebastian |