I'm starting to see what's going on, it seems that the optimization (according to sparql.org) gives
13 (disjunction 14 (assign ((?resp skos:altLabel)) 15 (bgp 16 (triple bdr:G844 ?rel ?res) 17 (triple ?res rdf:type :Place) 18 (triple ?res skos:altLabel ?reso) 19 )) 20 (assign ((?resp skos:prefLabel)) 21 (bgp 22 (triple bdr:G844 ?rel ?res) 23 (triple ?res rdf:type :Place) 24 (triple ?res skos:prefLabel ?reso) 25 )) [...] etc. instead of 13 (filter (in ?resp skos:altLabel skos:prefLabel skos:placeEvent :placeLat :placeLong :placeType :placeLocatedIn owl:sameAs tmp:entityScore) 14 (bgp 15 (triple bdr:G844 ?rel ?res) 16 (triple ?res rdf:type :Place) 17 (triple ?res ?resp ?reso) 18 )))) which I believe might result in a penalty... although frankly, I still can't understand how a very basic bgp like 21 (bgp 22 (triple bdr:G844 ?rel ?res) 23 (triple ?res rdf:type :Place) 24 (triple ?res skos:prefLabel ?reso) can take 100ms. Is there a way to tune the optimization level of features in queries or at the Fuseki level? Best, -- Elie
