Last modified: 2007-08-19 15:52:38 UTC
I'm new to this, so I'm not sure if I'm missing something; but in the table of results, the leftmost colum has no heading. Even if a specify heading for all columns, the left one is ignored; i.e. <ask>[[has_capital::|Country]][[has capital::*|Capital]]</ask> The Country text is just dropped, and no heading is produced; that specifiction seems to only tell it to show capitals for articles that have capitals, rather than just empty results from the first few articles.
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"?
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>?
(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).
