On Tue, Mar 18, 2014 at 11:59 AM, Chris Dollin <[email protected] > wrote:
> On Monday, March 17, 2014 06:17:10 PM Adam Retter wrote: > > > We did try using the: > > > > "yourSPARQLEndpoint elda:supportsNestedSelects true." > > > > Although I think we found that the option was actually (non-plural): > > > > "yourSPARQLEndpoint elda:supportsNestedSelect true." > > Oops, sorry. > Actually what we used in the end looked like:- <http://localhost:3030/catalogue/query> elda:supportsNestedSelect "true"^^xsd:string . Fuseki then said it was using nested selects (in the 500 error) - but it didn't make any difference to the problem. > > If the fix Rob made was to change from labelledDescribeViewer to > a simpler viewer like api:describerViewer then that's a confirmation > and I'll add an issue to the issues list. > > The thing is we do actually want the labels from all the viewed items as we use these elsewhere. As the generated union query seemed to be the root of the problem we switched to using our Elda construct extension so we could have an endpoint like this: spec:record-list a apivc:ListEndpoint ; apivc:uriTemplate "/record-list/{uuid}" ; apivc:variable [apivc:name "uuid"; apivc:type xsd:string] ; tna:construct """ CONSTRUCT { ?member rdfs:label ?label . } WHERE { ?recordList dcterms:identifier ?uuid ; dri:recordListMember ?member . ?member rdfs:label ?label . } """ . The query takes a while to run (there are approx 10,000 dri:recordListMember entries) but we get a result back eventually with no stack overflow problem. Rob -- Rob Walpole Email [email protected] Tel. +44 (0)7969 869881 Skype: RobertWalpolehttp://www.linkedin.com/in/robwalpole
