Support more query result signatures in run mode

[mkroetzsch]

The run parameter currently only works well with queries that have a single result variable called "entity". For the future, it would be good if more result schemas could be supported. More use cases for this interface include:

• Use case 1: Display entities together with additional results. Main usage: run an aggregate query that shows an additional number for every result (the query itself should then contain the group by and sorting directives needed to get the data, so the query interface would not need to know about this).
• Use case 2: Find and display statements. It would be good if we could find, e.g., statements that use a specific property as a qualifier. Statements appear as own resources in SPARQL, so it is not hard to query for them, but it would need a special display to show them.
• Use case 3: Find and display references. This is similar to the queries for statements. Again, the challenge is in displaying references in a form that makes sense to the user. Maybe this could also be done by showing the statement that uses them using the same approach as for use case 2.

Suggestions for addressing these use cases in the run API:

• One could have another URL parameter that specifies the columns that should be shown and how they should be populated. Some columns could be based on results that are found in the query result; in this case the variable name and "type" should be given. Some columns could be created indirectly, e.g., the current "label" and "description" columns that are fetched via the API.
• There could also be a parameter to specify what the "main entity" variable is called. Right now, it is always "entity" but a shorter name might be nicer for shorter URLs. Columns like "label" and "description" would refer to the entity variable. Columns that are supposed to show additional property values would also be based on the main entity.
• Not all kinds of SPARQL result types would need to be supported. The use cases above only need integers.
• To display statements, one could define a "statement variable" that holds the statement URI just as one has the "entity variable" for the case of entities. Statements are using URIs that contain their Statement-UIDs, which are prefixed by the entity that uses the statement. The URIs of statements have the form "wd:statement/Q60-5cc8fc79-4807-9800-dbea-fe9c20ab273b" or "wd:statement/q60-2fad2c45-4646-1e49-89b0-b8e958ffd7cf" (that is: "Q" and "q" may both occur in statements for Q60). The UID (e.g., "q60-2fad2c45-4646-1e49-89b0-b8e958ffd7cf") also occurs in the Web API JSON data, so one could in principle find it in View. Normally, the only incoming properties of statements should be the properties they use, so it is feasible to put them in the query. Example:

SELECT DISTINCT ?statement ?prop
WHERE {
  ?statement pq:P582 ?qvalue .
  ?entity ?prop ?statement
}
LIMIT 10

However, one may not need to use SPARQL for the property if one uses the API anyway to find all the relevant statement data based on its entity and UID. To display statements to the user, one should ideally show the entity that has the statement and all details about the statement (one could use a compact "value list + pop-over qualifiers" style as used in View for classes). Implementing this will be some work (on demand retrieval of statements, adjustments for display), so it may not be fully functional for a while, but the style of URL parameters etc. should be planned to support this in the future.

• References might be supported along a similar scheme, but there one will need more query variables to find the entity, since reference URIs may not contain the entity name at all.
• Since not all queries have an entity or statement variable, and references may even need multiple variables to decode, it might be better to avoid special parameters for setting the "main entity variable". Maybe one could just have this in the signature of the columns (e.g., cols=label(entity),desc(entity) to encode two columns that show the label and the description of the entity that the variable "entity" refers to; the price of such generality would be that the term fetching code is getting more complicated since there could be different entities in each result line -- maybe a simpler solution would also work). This scheme can also apply to property-displaying columns, e.g. prop(entity,P1234) could indicate a column that shows all P1234 values of the entity in variable "entity".