Hugh Williams
Mon, 07 Sep 2009 17:03:45 -0700
Hi Peter,
We are looking into the cause of this failing ORDER BY query you report ... Best Regards Hugh Williams Professional Services OpenLink Software Web: http://www.openlinksw.com Support: http://support.openlinksw.com Forums: http://boards.openlinksw.com/support On 7 Sep 2009, at 23:08, Peter Ansell wrote: > 2009/9/8 Richard Cyganiak <rich...@cyganiak.de>: >> On 7 Sep 2009, at 15:36, Bernhard Schandl wrote: >>> is there any way to limit the number of triples returned by a >>> DESCRIBE >>> query? The LIMIT clause of sparql obviously applies to the number of >>> result bindings, but each result binding may lead to an arbitrary >>> number of triples. >> >> Yes. There is no way to limit the number of triples in DESCRIBE, >> because the LIMIT clause in DESCRIBE applies to the number of >> described *resources*, not to the number of triples in those >> descriptions. >> >> I would perhaps execute the SELECT query that you give below, and >> then >> for each of the results of that query, run a "SELECT * WHERE {<uri> ? >> p ?o}" with a LIMIT clause, followed by "SELECT * WHERE {?s ?p >> <uri>}". > > You won't however pick up the contents of any nested blank nodes using > this method that would have been pulled in by the DESCRIBE > implementations on most SPARQL providers, both because they won't have > URI's to perform the SELECT on and because the final two sets of > queries only pull in one level of nodes. Also, any blank node > references in the results of the final SELECT queries can't be joined > because they are independent. This area of SPARQL is very messy due to > blank nodes, particularly as DESCRIBE hasn't been fully specified and > doesn't have configurable behaviour with respect to the GRAPH patterns > it uses when resolving the triples related to the resource so you > either use DESCRIBE and put up with the lack of a triple LIMIT or use > it and get stuck with everything at once even if you didn't want the > ?s ?p <uri> triples (where ?s is a URI) but you did want blank node > recursive closure. > >> Also note that LIMIT is not truly meaningful without ORDER BY. > > ORDER BY is quite slow on all current SPARQL implementations with > large datasources in the background. It is no wonder people don't use > it even though they technically should. And sometimes you even get > errors using ORDER BY [1] (when you didn't previously ;) ) as I did > when I attempted to add ORDER BY to this query: > > SELECT ?concept ?p ?o > WHERE { ?concept rdfs:label "Berlin"@en . ?concept ?p ?o .} > ORDER BY ?concept > LIMIT 5000 > > I am not sure if that error is a Virtuoso bug or a configuration bug. > > Cheers, > > Peter > > [1] http://tinyurl.com/nbbd94 > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Dbpedia-discussion mailing list > Dbpedia-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Dbpedia-discussion mailing list Dbpedia-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion