Re: [Bigdata-developers] problem with SPARQL update

[Michael S. <ms...@me...>]

Jim,

I had some thoughts on the scenario, here’s what I believe is going on. You are using WITH, which is defined as follows:

"The WITH clause defines the graph that will be modified or matched against for any of the subsequent elements (in DELETE, INSERT, or WHERE clauses) if they do not specify a graph explicitly. If not provided, then the default graph of the Graph Store (or an explicitly declared dataset in the WHERE clause) will be assumed. That is, a WITH clause may be viewed as syntactic sugar for wrapping both the QuadPatterns in subsequent DELETE and INSERT clauses, and likewise the GroupGraphPattern in the subsequent WHERE clause into GRAPH patterns.” (see http://www.w3.org/TR/sparql11-update/ <http://www.w3.org/TR/sparql11-update/>)

As I understand the standard, using a SELECT subquery introduces a new scope, so in query #2 your WHERE clause — namely, the inner SELECT query — applies to the *whole* graph, while in query #1 the pattern is evaluated against graph <http://kb.phenoscape.org/ic <http://kb.phenoscape.org/ic>> only. Assuming that the matching triples are not (or not completely) residing in that graph, this would explain why the first query returns immediately (and, as I understand, would be expected behaviour). So if your intention is to match against all graphs, but insert into a specific graph, you might try out the following (skipping WITH, but specifying the GRAPH in the INSERT clause):

PREFIX rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd:  <http://www.w3.org/2001/XMLSchema#>
PREFIX owl:  <http://www.w3.org/2002/07/owl#>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
PREFIX ps:   <http://purl.org/phenoscape/vocab.owl#>
PREFIX obo:  <http://purl.obolibrary.org/obo/>

INSERT {
   GRAPH <http://kb.phenoscape.org/ic> { ?annotation ps:reflexive_subClassOf ?subsumer }
}
WHERE {
   ?term ps:has_phenotypic_profile/rdf:type ?annotation .
   ?annotation rdfs:subClassOf* ?subsumer .
   FILTER(isIRI(?subsumer))
}

Does that one work in your scenario?

Best,
Michael



 
> On 11 Mar 2015, at 21:55, Jim Balhoff <ba...@ne...> wrote:
> 
>> On Mar 11, 2015, at 1:03 PM, Michael Schmidt <ms...@me...> wrote:
>> 
>> Jim,
>> 
>> first of all, I’d agree that the two queries are equivalent (unless I’m missing some typo here).
>> 
>> We’ve recently worked on improvements related to the evaluation of arbitrary length path operators (in your case: the transitive closure calculation over subClassOf), see http://trac.bigdata.com/ticket/1003. The fix there may help in terms of performance for both of your queries — as you may have noticed from previous discussions, we’re currently preparing the next release (planned for the end of the week), which will include this fix. We’d be happy to get your feedback whether this fixes the memory/performance of your query once the release is out.
> 
> After your message I tried the latest from the git master branch. It did change the performance of the update with the subquery: the memory increased more slowly, and although it did get close to maxing out, the update eventually completed, inserting 14,459,839 triples.
> 
> 
>> Regarding the problem with the update having no effect: would you mind sharing your curl call? Is your request following the guidelines documented at http://wiki.bigdata.com/wiki/index.php/NanoSparqlServer#UPDATE_.28SPARQL_1.1_UPDATE.29?
> 
> I am submitting it like this:
> 
> curl -X POST --data-binary @materialize_subsumer.rq  --header "Content-Type:application/sparql-update" http://example.org/sparql
> 
> This doesn't match the example on the wiki, but I think it is correct according to the protocol. And I think it worked for other updates. I tried pasting my update query into the web dashboard and it also returned immediately with zero mutations. This curl command did work for the version containing the subquery.
> 
> So it does seem like there could be something funny going on with the first query. I don't have very much time to investigate this week but I will try to reproduce it with some other queries later.
> 
> Thank you!
> Jim
>