Discuss Extension "Semantic Result Formats"

From semantic-mediawiki.org

Talk pages on this wiki should primarily be used to address possible mistakes as well as missing and superseded information in the documentation.
In case you are seeking support concerning individual questions, please have a look at this page. The Semantic MediaWiki user mailing list is always a good idea for seeking help.

archived talk

Configuration syntax changed?


The extension page gives $srfgFormats[] as the configuration parameter whereas the DefaultSettings.php uses smwgResultFormats[]. I suppose the information on the extension page is outdated?

Also, the list of formats enabled by default given in the "Configuration" section differs from DefaultSettings.php.

I can update the documentation but wanted to check first.

Best regards, Frank

MediaWiki 1.27.4 | PHP 5.6.25 | BlueSpice 2.27.3 | SRF 1.8

13:45, 18 January 2019

Note that you are using an very much outdated version of SRF. However in your version and current master $srfgFormats needs to be used.

13:37, 19 January 2019

Many thanks for your quick reply and this clarification.

15:46, 21 January 2019

> Also, the list of formats enabled by default given in the "Configuration" section differs from DefaultSettings.php.

Thank a lot: Good find! I just updated according to "DefaultSettings.php" in current master.

13:43, 19 January 2019

[1.27] Resourceloader timing issue

A thread, Thread:Extension talk:Semantic Result Formats/ 1.27 Resourceloader timing issue, was moved from here to Help talk:Jqplotseries format. This move was made by Kghbln (talk | contribs) on 22 May 2018 at 13:55.

query string sent with GET

Hi all,

we've created a latex export format. We've been using MediaWiki 1.24.2, Semantic MediaWiki 2.1.3 and Semantic Result Formats 2.1.2.

As result we receive a downloadable file test.tex Embedded html sourcecode of the result page:

<a href="http://www.old-wiki.de/images/3000/1/15/test.tex" class="internal" title="test.tex">test.tex</a>

Now we're using the same latex export format in MediaWiki 1.26.3, Semantic MediaWiki 2.4.1 and Semantic Result Formats 2.3. Now in the embedded html sourcecode of the result page the ask and latex query string with all parameters is sent completely with GET. In this example the url request is too long, so of course we receicve a 414 error and don't get a file.

<a target="_blank" rel="nofollow noreferrer noopener" class="external text" href="http://new-wiki.de/index.php?title=Spezial:Ask&...&...&">test.tex</a>

Not sure what has been changed in Sematic MediaWiki or Semantic Result Formats that causes the string to be sent with GET, where in the code is the method set?

Thanks a lot for any hint!

07:01, 6 October 2016

Admittedly this is much to esoteric to me. However, in case you do not get a helpful reply here you may probably also give the devoloper mailing list a shot.

09:19, 6 October 2016

> we've created a latex export format. We've been using MediaWiki 1.24.2, Semantic MediaWiki 2.1.3 and Semantic Result Formats 2.1.2. As result we receive a downloadable file test.tex Embedded html sourcecode of the result page:

As to my knowledge, we have changed nothing to the underlying structure of how links are generated. Links to file formats have always been send [0] via GET to `Special:Ask`.

Without the code, I'm unable to pinpoint to the cause but one thing is clear the href has changed from being `class="internal" title="test.tex"` to `rel="nofollow noreferrer noopener" class="external text"` and rendering links is being done by the MediaWiki parser not by SMW.

[0] http://sandbox.semantic-mediawiki.org/wiki/FileResultDownloadLink

03:29, 9 October 2016

format=sum incorrect compared with default format (manuall summed)

Running into an issue with incorrect sum compared with Default record view.

Asking for sum of harvest measured in lbs gives me 62

{{#ask: [[Has base type::Harvest]][[Has unit::lbs]] |?Harvest Amount |format=sum}}

While displaying records in table and adding manually i'm getting arund 111+

{{#ask: [[Has base type::Harvest]][[Has unit::lbs]] |?Harvest Amount }}

Reading some other threads here I've tried SemanticAdmin refresh w/ runjobs but the numbers remain the same.

example instance [1]

23:55, 24 August 2016
{{#ask: [[Has base type::Harvest]][[Has unit::lbs]]
 |?Harvest Amount

A #ask query is by default set to a limit of 50 (Con­figu­ration para­meter "$smwgQDefaultLimit").

Your table query on the other hand sets a specific limit hence the discrepancy and I'd suggest you adapt your sum query to the same limitation.

{{#ask: [[Has base type::Harvest]][[Has unit::lbs]]
|?Harvest Amount
03:26, 25 August 2016

Perfect, Thanks MWJames. Interesting to note that format=count is not subject to limit.

04:02, 26 August 2016

Min y-axis not working for jQPlotSeries stacked series

I am having issues getting the y-axis to start at 0 when using the stacked series option in the bar chart. I used the Demo data and put and example here. You can even see the second column's data value is listed below the x-axis. (It is difficult to see...near "BB"). I have added the min parameter, but there was no change. Thank you in advance for any assistance.

14:34, 20 March 2015

> I am having issues getting the y-axis to start at 0 when using the stacked series option in the bar chart. I used the Demo data and put and example here.

Please have a look at [0], it seems that 'data.parameters.stackseries' uses jqplot autoscale. I'm not sure whether jqplot/bar/stack itself can be adjusted or not but I recommend you try tweaking those options available and see the results.

[0] https://github.com/SemanticMediaWiki/SemanticResultFormats/blob/master/formats/jqplot/resources/ext.srf.jqplot.chart.bar.js#L93

[1] https://stackoverflow.com/questions/7837346/how-can-i-display-a-jqplot-stacked-bar-graph-when-xaxis-is-text

[2] https://stackoverflow.com/questions/9046987/jqplot-individual-values-not-totals-in-stacked-chart

[3] http://www.jqplot.com/deploy/dist/examples/barTest.html

15:17, 20 March 2015

Below is what I found fixes the issue I was having.

Starting at line 93 in SemanticResultFormats/formats/jqplot/resources/ext.srf.jqplot.chart.bar.js

// Number axis 
var numberaxis = { 
	  ticks: data.parameters.stackseries || data.parameters.autoscale ?  [] : data.ticks, // use autoscale for staked series 
	  label: data.parameters.numbersaxislabel, 
	  labelRenderer: $.jqplot.CanvasAxisLabelRenderer, 
	- autoscale: data.parameters.stackseries || data.parameters.autoscale ? true : false, 
	+ autoscale: data.parameters.autoscale ? true : false,     //do not use autoscale for stacked series
	- padMax: 0, 
	+ padMax: 0.5,    // make some room at the top
	  padMin: 0, 
	+ min: 0,         // force min = 0 (should be changed to accept min param)
	  tickOptions: { 
	     angle: data.parameters.direction === 'horizontal' ? 0 : -40, 
	     formatString: !data.parameters.valueformat ? '%d' : data.parameters.valueformat  // %d default 
18:51, 24 March 2015
20:32, 24 March 2015

Thanks. I hope this helps someone else out there.

19:06, 25 March 2015

blockUI requires jQuery v1.3 or later! You are using v1.11.1

Edited by author.
Last edit: 16:31, 11 March 2015

I'm getting the error

"blockUI requires jQuery v1.3 or later!  You are using v1.11.1"

in a fresh installation when loading a datatable. This is MW 1.24.1, SMW 2.1.1, SRF 1.9.

I've added wgIncludejQueryMigrate = true; to LocalSettings.php, that didn't help. As I understand it from this discussion https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/356#issuecomment-47365754 that should fix the problem, but it does not on my end.

I got it working by commenting out the following:

if (/^1\.(0|1|2)/.test($.fn.jquery)) {
                      /*global alert:true */
                      alert('blockUI requires jQuery v1.3 or later!  You are using v' + $.fn.jquery);

In the file:


Is there a less icky way to do this?

16:18, 11 March 2015

> SRF 1.9.

You should update to the most recent SRF 2.1*.

16:30, 11 March 2015

OK, will do. Thanks! I was blindly following the instructions here which say 1.9.*. Am I missing something or do those instructions need updating?

16:35, 11 March 2015

Well, there is always room for improvement I believe. The following diff should help the cause.

17:37, 11 March 2015


14:48, 12 March 2015

multiple #subobject in one page


I have multiple subobjects on pages. For example:

|Bezeichnung=Task 01
|Anmerkungen=Test 2
|TeilProjekt=EDV-Projekte/ZI TEST 01
|Bezeichnung=Task 02
|Status=im Plan
|Anmerkungen=Test 3
|TeilProjekt=EDV-Projekte/ZI TEST 01
|Bezeichnung=Test 3
|Status=im Verzug
|TeilProjekt=EDV-Projekte/ZI TEST 01

with the query...

{{#ask: [[-Has subobject::{{PAGENAME}}]] 
| mainlabel=-
| ?Bezeichnung
| ?Bearbeiter
| ?Datum
| ?Status
| ?FaelligBis = Fällig bis
| index=0
| link=all
| format=broadtable
| headers=plain
| class=sortable wikitable smwtable
| default=keine Teilprojekte / Aufgaben gefunden

I can see all all subobjects of the page:

Projektname Bezeichnung Bearbeiter Datum Status Fällig bis
EDV-Projekte/ZI TEST 01 Task 01
Task 02
Test 3
10 März 2015 unbearbeitet
im Plan
im Verzug
31 März 2016
31 März 2018
26 November 2015

BUT all entries appear in one table row. Is there a possibility to show every subobject in one row like this:

Projektname Bezeichnung Bearbeiter Datum Status Fällig bis
EDV-Projekte/ZI TEST 01 Task 01 MZ 10 März 2015 unbearbeitet 31 März 2016
EDV-Projekte/ZI TEST 01 Task 02 MZ 10 März 2015 im Plan 31 März 2018
EDV-Projekte/ZI TEST 01 Test 3 MS 10 März 2015 im Verzug 26 November 2015

Thank you in advance


13:39, 10 March 2015

I can't seemed to find anything wrong with your example, see Examples/Queries/Subobject to display table rows

12:58, 11 March 2015

It looks like I had a problem with my SMW installation. After reinstalling and updating the database now all looks fine :-). Thank you for your help.

10:49, 12 March 2015

Good to read. The positive side-effect is also that we now have a concise example for this.

13:24, 12 March 2015

[workaround] Gallery / PHP Fatal error: Call to a member function isSpecialPage() on a non-object in Gallery.php on line 70

The SemanticResultFormat 1.9.2 "Gallery" is not fully operative with MW 1.23+ anymore. ("TagCloud" as well!)

The problem was discussed at https://github.com/SemanticMediaWiki/SemanticResultFormats/issues/35 and solved uncompletely at https://github.com/SemanticMediaWiki/SemanticResultFormats/commit/d48a7b1df17066d43567d7c738d7aa1dc489056f . To complete this workaround, please have a look at following changes in file extensions/SemanticResultFormats/formats/gallery/Gallery.php to bypass the problem:

@@ -49,6 +49,16 @@
 		return $this->getResultText( $results, $this->outputMode );
+	private function isSpecialPage() {
+		$title = $this->getContext()->getTitle();
+		return $title instanceof \Title && $title->isSpecialPage();
+		}
+	private function getNsText($file) {
+		$languagepage = $this->getContext()->getTitle();
+		return $languagepage instanceof \Title && $languagepage->getNsText( $file );
+		}
 	 * @see SMWResultPrinter::getResultText
@@ -67,7 +77,7 @@
 		// No need for a special page to use the parser but for the "normal" page
 		// view we have to ensure caption text is parsed correctly through the parser
-		if ( !$this->getContext()->getTitle()->isSpecialPage() ) {
+		if ( !$this->isSpecialPage() ) {
 			$ig->setParser( $GLOBALS['wgParser'] );
@@ -161,7 +171,7 @@
 				'class'  => 'srf-gallery' . $class,
 				'align'  => 'justify',
 				'data-redirect-type' => $redirectType,
-				'data-ns-text' => $this->getContext()->getTitle()->getPageLanguage()->getNsText( NS_FILE )
+				'data-ns-text' => $this->getNsText( NS_FILE )
 			$html = Html::rawElement( 'div', $attribs, $processing . $ig->toHTML() );
@@ -306,7 +316,7 @@
 				$imgCaption = '';
 		} else {
-			if ( $imgTitle instanceof Title && $imgTitle->getNamespace() == NS_FILE && !$this->getContext()->getTitle()->isSpecialPage() ) {
+			if ( $imgTitle instanceof Title && $imgTitle->getNamespace() == NS_FILE && !$this->isSpecialPage() ) {
 				$imgCaption = $ig->mParser->recursiveTagParse( $imgCaption );

Good luck,

15:56, 6 July 2014

It works!!! Thank you so much for this! Finally runJobs.php works again!

23:41, 10 February 2015

Incorrect Sum if more than one property has same numerical value

On my wiki, Property:Regimen has type::number and is used on pages with [[Category:Chemotherapy regimens]].

If I have: [[Regimen::1]] + [[Regimen::1]] + [[Regimen::1]] + [[Regimen::2]] + [[Regimen::4]] + [[Regimen::10]] + [[Regimen::20]] + [[Regimen::40]]

And {{#ask: [[Category:Chemotherapy regimens]] | ?Regimen | format=sum }}

Then the output sum that's listed is 77, which is 1 + 2 + 4 + 10 + 20 + 40. It leaves out two out of the three [[Regimen::1]] values.

This is a problem for me because I want to label various areas on different pages as [[Regimen::1] (or actually {{#set:Regimen=1}}) and then add up the number of times I used the label. Is this a bug, or am I doing something wrong? Thank you.

05:57, 28 January 2015

No, the sum is correct based on the declaration of `[[Regimen::1]] [[Regimen::1]][[Regimen::1]]` which is equal to `[[Regimen::1]]` due to `[[Regimen::1]]` representing the same fact about the subject X possessing an attribute of `Regimen` with `1`.

Modeling is based on a declarative attribute not a mere collection of added annotation like `[[Regimen::1]] [[Regimen::1]] ...` if you need to add the same fact (being Regimen=1) then I'd suggested you have a look at the subobject to model your data (see Examples/Queries/Aggregating numbers).

07:14, 28 January 2015

Thank you very much, I appreciate your response. I've taken your example and worked out something that can work for me (I understand that I don't need to separate #subobject:1, etc. like this, but it's how my use case will be):

Total Regimens: {{#ask: [[Regimen::+]]

Total Variants: {{#ask: [[Variant::+]]

As a trial, I've put the above data on two separate pages, but I'm confused why the query only returns the sum from a single page (Regimens: 2; Variants: 5) rather than across the entire site (which I thought was the default). What needs to be changed about my query to be able to calculate a total for the number of times Regimen=1 and Variant=1 is used throughout the entire wiki?

To verify, Special:Properties shows:

Regimen of type Number (4 uses)
Variant of type Number (10 uses)

I'd just like to be able to display this as a number elsewhere on the site. In case it helps, the pages are: http://hemonc.org/wiki/Editing_test_page http://hemonc.org/wiki/Editing_test_page_2

Is there any way to avoid needing to manually assign #subobject:n, #subobject:n+1, #subobject:n+2, etc.? It doesn't appear so....

Thank you again--we're planning on utilizing many other functions of Semantic Mediawiki once we can learn the basics.

09:24, 28 January 2015

> Is there any way to avoid needing to manually assign #subobject:n, #subobject:n+1, #subobject:n+2, etc.? It doesn't appear so....

Rather then trying to follow the normal "data hoarding" approach, SMW enforces some conceptional restrictions on how "facts" can and should be modeled (e.g. Help:Classification).

The main object of interest to describe something is the subject (which in most cases is a wikipage) and by assigning a predicate together with a value (e.g. Regimen=1 and Variant=1) one describes this subject though those attributes. If such attributive declaration represents the same "fact" it is handled as the same entity of knowledge (a thing that describes the subject and therefore only appears once).

The same principle about "describing the same thing" is applied to subobjects. If a subobject contains the same declarations then it is being recognized as being the same (technically a hash is produced to compare those entities) unless it describes something different (using an explicit name opposed to the auto-identifier given without an explicit name). Using a different name on a subobject embedded within the same subject creates an independent entity about something that may or may not describe by the same facts.



represents the same fact while


are equal in its declaration to produce the same annotation but are different to the end that it represents Subject X#Foo and the other Subject X#Bar. While it may seem to split hairs nevertheless it creates a clear and explicit distinction between those two subobjects.

The same thing can be achieved by using `@sortkey` (those are not equal hence treated as different entities and therefore can be queried individually):


PS: Sorry for the lengthy reply and I hope it explains the issue a bit better.

PSS: If you are unsure about how to model your content, it is always recommended to ask on the Semantic MediaWiki mailing lists for suggestions or if you encounter a technical issue to refer to [0].

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues

10:50, 28 January 2015

Thank you again. I believe I understand the reason for things being structured this way--I just wish there was a slightly easier alternative for my use case.


As a trial, I've put the above data on two separate pages, but I'm confused why the query only returns the sum from a single page (Regimens: 2; Variants: 5) rather than across the entire site (which I thought was the default). 

It is now displaying the proper totals Sum Regimen: 4 Sum Variant: 10

So this delayed update was likely due to caching or something else on my side. I had emailed the mailing list--that message is still in the moderation queue.

14:39, 28 January 2015

Charting over 1000 data points

I'm certainly unlucky, but I've yet to succeed once in creating a semantic graph. For example failures of the simple histogram kind, see [1] and [2].

I've tried many tweaks by following docs for different formats and suggestions by Special:Ask itself, but the outcome is always the same:

  1. either a graph is shown based on a random subset of the data points (i.e. completely false);
  2. or no graph is shown at all (sometimes a helpful message "The chart or graph is empty due to missing data" is shown instead).

Now, I understand there is a limit in how resource-intensive a graph can be, but the docs (here or on mw.o) don't even mention this error at all. Example questions I'd like the docs to answer:

  1. how many data points you can reasonably expect to succeed in charting;
  2. whether increasing the semantic results limit in wiki configuration helps, or any other configuration tweak is possible;
  3. if some of the chart formats is more likely to succeed;
  4. whether I can exclude there are errors in my query where the same query succeeds in other formats (e.g. standard count or list);
  5. if there is some way to optimise the queries so that some data is sent to the format;
  6. how to make the chart display some error or footnote or whatever when some data was skipped;
  7. how to break down a chart in multiple charts which don't fail.
10:11, 9 November 2014

MW 1.24alpha compatibility

See also the bug suggestion and discussion on GitHub

In addition, until the file is merged into the master branch, you may have to manually substitute jquery.blockUI.js or else kill the if clause in the beginning of your existing file.

IMHO, it's now possible to have SRF running on MW 1.24. My rationale for working with MW 1.24 alpha was to test the VisualEditor (it also works)

18:00, 27 June 2014

Datatables formatting options

Is there any way to format the datatables output? To pivot it?

21:00, 7 March 2014

Not sure what you mean by "format the datatables output" but if you are looking for pivot support you might be interested in [0] which uses DataTables as output representation. I'm not planning to work on this in near future, so please feel free to implement it.

[0] http://rjackson.github.io/pivot.js/

22:44, 7 March 2014

Filtered format broken after PHP upgrade

After upgrading from PHP 5.4.13 to 5.4.16 the filtered format will now only show one result. I have not noticed this issue with any other result format. Please help.

17:53, 3 July 2013

Still broken when upgrading to PHP 5.4.17. Filtered result format only shows the last result. Is anyone else experiencing this problem?

14:49, 10 July 2013

This is still an issue upgrading to PHP 5.4.20. Is anyone else experiencing this issue?

18:48, 4 December 2013

"I have a spinning wheel but no output " How to Repair the JavaScript resource ?


I have read your tip about finding the delinquent JavaScript resource but I dont find the final solution in order to show the eventimeline on my website :


Could you help me ?


Nicolas NALLET (Sémantiki)

20:31, 11 June 2013

First you have to use &debug=true and looking at it, the error says "TypeError: Cannot call method 'getTime' of null" which is coming from Timelines units.js:51.

I guess (I really haven't looked at it) from the error message that the query[1] returns some incompatible dates that Timeline can't handle and therefore is failing with "'getTime' of null".

[1] Query

03:07, 12 June 2013

Thanks it works,


Nicolas NALLET (Sémantiki)

19:56, 5 July 2013

Good Ole Min and Max

I'm upgrading with the latest ParserExtension and once again I need to manually add support for #min and #max. It seems like they used to be there, is there any reason why they were pulled, and why they seem to be banned? Vote to add them back +1.

20:32, 11 June 2013

Min/max are still part of SRF. For more see Help:Math related result formats (Pages also include examples)

02:58, 12 June 2013

Doesn't run on MediaWiki 1.19 minimal requirements

The release notes of Semantic Result Formats version 1.8 state full compatibility with MediaWiki 1.19. However, this is not completely true.

MediaWiki 1.19 has a minimum requirement of PHP v.5.0.2, but Semantic Result Formats uses PHP 5.3 functions in some places. So if you are running MediaWiki 1.19 with ie PHP 5.2.4, SRF (in fact, the entire wiki) breaks.

At the moment, the issues I have traced concern the use of the PHP __DIR__ magic constant, in three places:

 Resources.php (2 hits)
   Line 32: 	'localBasePath' => __DIR__ ,
   Line 37: 	'localBasePath' => __DIR__ . '/formats',
 SemanticResultFormats.php (1 hit)
   Line 67: $wgResourceModules = array_merge( $wgResourceModules, include( __DIR__ . "/Resources.php" ) );

Replacing the __DIR__ constant with dirname(__FILE__) in all three occurences, fixes the issue.

I have, however, not looked for every new PHP 5.3 function being used.

I think you should either update the code, or update the documentation.

11:35, 11 January 2013

Your observation is correct and thank you for pointing this out. I will forward this to the programmer to see if there will be a 1.8.1 release without the PHP 5.3+ requirement end of the month.

22:07, 11 January 2013

I have opended bug 43924 to address this problem. Cheers

16:49, 13 January 2013


I saw that ‎Siebrand has modified the Translatewiki part, yet I can still see this project on the Translatewiki.net. So, has it changed or not?

10:45, 3 January 2013

He has a problem with one or two people an thus refuses to support the work of heaps of other programmers. That's how it appears to me at the moment. To cut a long story short: I believe he will fix this issue on tw.n. Cheers

12:01, 3 January 2013

Legacy documentation

Hi again,

having to lag behind the current versions of SMW, I noticed that the documentation of deprecated result formats is broken due to the queries used, e.g. Help:RSS_format.

Could that be fixed? Would you consider it possible to hold available older versions of the documentation for those having to use the corresponding software, for what ever reason?

Thanks for your efforts and so!



11:51, 19 December 2012

Heiya Argi,

I see your poblem and it is indeed a valid request too. The problem is that this wiki always uses the newest versions of the software to ensure that the new formats etc. are supported along with their documentation. At the same time the support for unsupported formats vanishes as a kind of collateral damage. I am afraid that the only solution is to copy over the smwdoc documentation from an older installation. However you may generated it locally too since you run an older version: See this page on how to generate it locally


02:22, 20 December 2012

sep seems not to work for tree format

A thread, Thread:Talk:Semantic Result Formats/sep seems not to work for tree format, was moved from here to Help talk:Tree format. This move was made by Kghbln (talk | contribs) on 20 December 2012 at 01:13.

Exhibit output format -- still active?


I understand that output format Exhibit has been replaced by format "filtered". But it's unclear if all functionality has been replaced. I'm specifically interested to know if/how visualisations on maps have been replicated (for example, http://www.simile-widgets.org/exhibit/examples/billionaires/billionaires.html or something similar is a visualisation I'd like to use). I've reviewed materials on Maps and Semantic Maps, but those do not seem to be useful for such visualisations.

Patelmm79 (talk) 22:21, 23 November 2012 (CET)

22:21, 23 November 2012

I am afraid not. So far only a list and a calendar view is supported by the new format "filtered". However the architecture allows to extend "filtered" with more views.

23:43, 23 November 2012