Browser chokes with large number of named graphs in dataset

[jaw111]

I have a dataset with ~0.5M named graphs in it. The SPARQL SELECT query that gets the named graph IRIs with count of triples returns 150MB of JSON and the browser falls over on it.

Probably it doesn't make sense to try and display that many choices in the Graph IRI drop down anyway, so might make sense to put a reasonable limit (1000) on the number of results that get returned by the query.

[jaw111]

It might be an idea to auto-suggest graph IRIs to the user as they type in the Graph IRI input field. This could then be used to fetch some matching graphs from the repository using a query like:

SELECT ?graphIRI (COUNT(*) AS ?triples) {
  {
    SELECT ?graphIRI {
      GRAPH ?graphIRI {}
      FILTER STRSTARTS(STR(?graphIRI), "http://example.com/")
    }
    ORDER BY ?graphIRI
    LIMIT 10
  }
  {
    GRAPH ?graphIRI { ?s ?p ?o }
  } UNION {
    ?s ?p ?o
  }
}

GROUP BY ?graphIRI

[jaw111]

The implemented query now gives a timeout (after 60s limit). The following query completes in reasonable time (~6s) on my test dataset:

SELECT ?graphIRI ?triples {
  {
    SELECT ?graphIRI (COUNT(*) AS ?triples) {
      {
        {
          SELECT DISTINCT ?graphIRI {
            {
              graph ?graphIRI {}
              FILTER STRSTARTS(STR(?graphIRI), "http://example.com/foo")
            }
            UNION
            {
              graph ?graphIRI {}
            }
          }
          LIMIT 500
        }
        GRAPH ?graphIRI { ?s ?p ?o }
      }
    }
    GROUP BY ?graphIRI
  }
  UNION
  {
    SELECT (COUNT(*) AS ?triples) {
      ?s ?p ?o
    }
  }
}

[jiemakel]

Hmm, we're losing the ordering/selection by graph size, but maybe that's not so bad. I was not sure anyway whether one would want ordering by graph IRI or by graph size in that list. I'll commit your version.