Add "Explore endpoint" feature

[jneubert]

After the discovery of a new endpoint, it is useful to be able to get some information about it. I'd suggest to add some predefined queries for this purpose:

Lookup and count classes:

# count the classes used in the dataset

select (count(?class) as ?count) ?class
where {
  ?x a ?class 
}
group by ?class
order by desc(?count)

Lookup and count properties:

# count the properties used in the dataset

select (count(?property) as ?count) ?property
where {
  ?x ?property [] 
}
group by ?property
order by desc(?count)

Lookup and count named graph triples:

# count the triples of the named graphs used in the dataset (if any)

select (count(?s) as ?count) ?graph
where {
  graph ?graph { ?s ?p [] }
}
group by ?graph
order by desc(?count)

The queries are expensive, so the results should be cached (perhaps with some "force" option under Configure/Refresh data).

I get a Javascript warning re. "long running query" when executing the queries on dbpedia - yet the query is executed successfully when clicking "continue". Not sure if the timeout setting could be ajusted here.

Of course, the results of the queries could be used for autosuggest; maybe even for ordering the suggestions according to the frequency of their occurence in the dataset at hand.

The feature could be integrated into the UI via a "Explore endpoint" menu besides "Configure request", perhaps simply with "Classes", "Properties" and "Named graphs".

[LaurensRietveld]

Indeed, one of the bigger problems when dealing with endpoints is knowing what is in there.

The problem with these expensive queries, is that some endpoints will simply fall over.. I've experienced this issue when I implemented the property and class autocompletion features, where I query for all distinct properties and classes. This

I guess most current SPARQL endpoints are not suitable for these kind of queries. Ideally, I would like to rely on void descriptions (see issue #111) instead. Sadly, most endpoints do not support void yet (see http://sparqles.okfn.org/discoverability)

[jneubert]

Hmm - after some arbitrary tests, you sadly seem to be right on endpoints not responding to the exploratory queries. Some of them however don't respond at all.

It looks like you currently can't rely on anything. However, the queries - if they work - should give an accurate image of what is in the endpoint (which is not necessarily true for void descriptions, which may be outdated and/or incomplete).

If the queries would loaded into the main window before they are executed, the user should be able to understand that it is not the fault of yasgui when the information cannot be obtained. Perhaps, a more explanatory message ("endpoint is not available", "endpoint reports a system errror", "endpoint rejects query") could be added to the response, which makes this even more clear.

So I'd argue that the support of such queries would offer another way for possibly getting relevant information for unexperienced users, and would save time for copy+pasting for the more experienced ones.