This is very implementation dependent. For instance, it is permissible for an RDF database to store the same triple multiple times. It just needs to make sure there are no duplicates when it gets around to handling SPARQL requests.
One case of this is for bulk loading of data, it may make sense to accept all the presented triples into a new structure as if they were completely new, and to determine if there are duplicates in a background thread that merges the new structure with existing data. (In the meantime, queries against the dataset will need to do some expensive checks for duplicates until the merge is complete, but this is an implementation detail). Knowledge of how many new triples were actually asserted isn't available until the background thread is complete, and this could be a long time after the initial load operation returned. I know of two systems that do just this, and I believe there are more. Another reason is because SPARQL has attempted to be compatible with as many existing systems as possible. This is one of the outcomes of the committee process. A lot of systems were not returning this information with an update, so it would not have been appealing to suddenly start providing it. It's not very easy to get a committee to commit to something that doesn't appeal to many of it's members. Regards, Paul On Tue, Sep 4, 2012 at 2:06 PM, Laurent Pellegrino <[email protected]> wrote: > Thank you Paul for your very clear answer. > > Do you know if there is a technical reason for not providing > additional methods that return deleted/altered entries or a counter? > It seems strange for me that the specification do not discuss about > that. > > Kind Regards, > > Laurent > > On Tue, Sep 4, 2012 at 7:31 PM, Paul Gearon <[email protected]> wrote: >> On Tue, Sep 4, 2012 at 10:27 AM, Laurent Pellegrino >> <[email protected]> wrote: >>> Hello all, >>> >>> Is it possible to retrieve the entries which have been deleted/updated >>> during the execution of a SPARQL update query or at least to know the >>> number of entries which have been altered? >> >> Not specifically, no. >> >> However, you can probably figure it out before you do the operation. >> Most INSERT or DELETE operations can be converted into a CONSTRUCT or >> SELECT query, which gives you a starting point. For an INSERT you can >> then figure out the new data using EXISTS, and for DELETE you can use >> NOT EXISTS. >> >> So, say you want to execute: >> >> INSERT { ?s foaf:name ?name } >> WHERE { ?s foaf:givenName ?gn . >> ?s foaf:familyName ?fn >> BIND (concat(?gn, " ", ?fn) as ?name) >> } >> >> To see the attempted insertions, you just change this to: >> >> >> SELECT ?s (foaf:name AS ?prop) ?name >> WHERE { ?s foaf:givenName ?gn . >> ?s foaf:familyName ?fn >> BIND (concat(?gn, " ", ?fn) as ?name) >> } >> >> The use of "AS ?prop" allows the inclusion if an IRI in the result >> set, which is needed if you want to see the middle column in a SELECT >> (you could just drop the middle column here, but I'm trying to make it >> look consistent with triples that are inserted). CONSTRUCT doesn't >> need this. >> >> To restrict to just the data you want to insert, you can use: >> >> SELECT ?s (foaf:name AS ?prop) ?name >> WHERE { ?s foaf:givenName ?gn . >> ?s foaf:familyName ?fn >> BIND (concat(?gn, " ", ?fn) as ?name) >> FILTER NOT EXISTS { ?s foaf:name ?name } >> } >> >> To see the number of entries, just replace the variables in the SELECT >> clause with a COUNT(DISTINCT *) >> >> >> SELECT COUNT(DISTINCT *) >> WHERE { ?s foaf:givenName ?gn . >> ?s foaf:familyName ?fn >> BIND (concat(?gn, " ", ?fn) as ?name) >> FILTER NOT EXISTS { ?s foaf:name ?name } >> } >> >> A similar approach may be taken for DELETE. An expression that >> performs both INSERT and DELETE may be more difficult in the general >> case, but should be tractable for most applications. >> >> Regards, >> Paul Gearon
