ssanbeg wrote:

OK, I found the mainlabel parameter, which is missing from most of the examples.
I still think using the normal anchor text syntax (maybe concatenating them
together) is more inuitive, but since it can be done, I'll lower the priority.

The above example is no proper query. If it works, this is our fault. But it
should not and it might break any time. Proper syntax is

[[has capital::*|Capital]] (print "has capital" relations in a column "capital")
[[has capital::+]] (show all things with at least one "has capital" relation)
[[has capital::Paris]] (show all things with a "has capital" relation to "Paris")

Only statements with "*" are about printing another column, and so only there
can a label for said coolumn be chosen. Since no statement corresponds to the
first (main) column, you cannot set its label in this way.

What do you mean with "normal anchor text syntax"?

ssanbeg wrote:

Oh, that's odd. I wouldn't have guessed that something else was needed after
the ::, since it seems to be sufficient, and + is a valid article name.

But what I was referring to is that it's not intuitive how to get the heading
for the left column. If I specify text after the | on both columns, it parses
them OK, since it resolves the links, and generates the data. But on the right
column, the specified text is used as a heading, while on the left is silently
discarded.

It seems like the more intuitive way would be to concatenate the text for all of
the left column specifiers, so that way it would work no matter where it was
put. Paring it and ignoring it just seems bad.

Granted, at some level it makes sense that since the left column is handled
differently, its text would also be handled differently. But from a user
perspective, as long as we can parse the text from the first statement, it would
be more intuitive to use that, instead of having to figure out another syntax to
specify it.

"+" used to be illegal in article names until very recently. This has changed,
but we cannot change the syntax of <ask> so easily (it is used in existing
wikis). We will need to introduce some escaping mechanism for handling such
articles (I think there are no spare symbols for our purpose).

I get your point considering the (un)intuitiveness of the current approach. I am
not sure whether concatenating is the best solution, but it could be done and
seems also more intuitive to me. Should we then also concatenate the text given
via the "mainlabel" parameter of <ask>?

ssanbeg wrote:

(In reply to comment #4)

"+" used to be illegal in article names until very recently. This has changed,
but we cannot change the syntax of <ask> so easily (it is used in existing
wikis). We will need to introduce some escaping mechanism for handling such
articles (I think there are no spare symbols for our purpose).

Maybe some kind of quoting, like [[has operator:[[+]]]], which is only slightly
odd; not much more than a linked image caption, though/

I get your point considering the (un)intuitiveness of the current approach. I am
not sure whether concatenating is the best solution, but it could be done and
seems also more intuitive to me. Should we then also concatenate the text given
via the "mainlabel" parameter of <ask>?

That seems reasonable, if for nothing else then backwards compatability. I
think most of the time, people would specify the label in only one place, but
it's hard to guess which place that would be, so concatenating them shold work.
It's likely that when someone does specify more than one, it is by mistake;
then, concatenating should make it obvious what their mistake was, so it will be
clear how they can fix it.

The new (SVN) version now allows to specify the mainlabel parameter via pipe syntax in all conditions of the query (the parts with * are no conditions and behave as before), just as you suggested. If many labels are given, the result is created as a concatenation of all parts, in the hope that this helps users to clean up the mess.

For properties that link to pages (the former relations), escaping is possible via an extra ":". So <ask>[[has operator:::+]]</ask> should work. There is no such escaping for other datatypes yet (but this would be another feature request).