Extension talk:Semantic Drilldown

Sort order in drilldown results
Is it possible to order the results by their frequency? --Dusanson 17:17, 28 January 2012 (UTC)


 * Hi - unfortunately, no. Yaron Koren 14:41, 29 January 2012 (UTC)

has drilldown title property not working
I am unable to get the "has drilldown title" property working. I set it in my category here: http://thisishowyouplay.com/wiki/Special:Browse/Category:Activities

but when I try to browse data, it still says "browse data" on this page: http://thisishowyouplay.com/wiki/Special:BrowseData/Activities?_single

thanks again. Chrisisready 02:27, 12 February 2012 (UTC)


 * Yes - you've discovered a problem that seems to occur with more recent versions of MediaWiki - starting with MW 1.18 or 1.18.1. I think I just fixed it in SVN - see here. Yaron Koren 16:10, 12 February 2012 (UTC)
 * Thanks Yaron! The patch worked great. You're the best. Chrisisready 19:09, 12 February 2012 (UTC)

After the upgrade from 1.17.x to 1.18.1 the DrillDown gave up working
My configuration: and
 * MediaWiki	1.18.1
 * PHP	5.2.17 (cgi)
 * MySQL	5.0.91mm-log
 * Semantic Bundle (Version 20120124)
 * Semantic Forms (Version 2.3.2)
 * Semantic MediaWiki (Version 1.7.0.2)

http://tunearch.org/Special:BrowseData now shows just a list of articles in category, in alphabetical order. Are there configuration issues related to the semantic bundle that I'm missing?

I have entered the following in my LocalSettings.php $sdgNamespaceIndex = 170; require_once( "$IP/extensions/semantic-bundle/SemanticBundleSettings.php" ); require_once( "$IP/extensions/semantic-bundle/SemanticBundle.php" );
 * 1) THE SEMANTIC BUNDLE  ######

and this in the $IP/extensions/SemanticBundleSettings.php include_once( "$IP/extensions/SemanticDrilldown/SemanticDrilldown.php" ); $sdgShowCategoriesAsTabs = false; $sdgFiltersSmallestFontSize=9; $sdgFiltersLargestFontSize=25; $sdgNumResultsColumns=1; $sdgNumResultsPerPage=250;
 * 1) Semantic Drilldown
 * 2) More info: http://www.mediawiki.org/wiki/Extension:Semantic_Drilldown#Installation

I also run the $IP/extensions/SemanticMediaWiki/maintenance/SMW_refreshData.php more than once... nothing happened. Please help! VALERIO M. PELLICCIONI - 18:46, 12 February 2012 (GMT+1)


 * Hi - it looks like you got both the URL and the date wrong... anyway, this looks like the page you're talking about, and the filters seem to be working correctly there. Is there still a problem? Yaron Koren (talk) 19:30, 9 March 2012 (UTC)

Slow to load page links on Semantic Drilldown
UPDATE!!!!: The problem seems to only exist in Chrome. Are there any known incompatibilities or conflicts with Chrome?

Hello -- I have several filters set up and on one of them, there are serious performance issues. The links to pages that meet the criteria load immediately, but it takes 10 seconds until they can be clicked on. On some filters, things work fine but on the one with perhaps several hundred values, it is very laggy. What is a reasonable number of values a filter can have before performance suffers?

I know that one option is to have a restricted set of values and to use a Combo Box. However, I'd greatly prefer not to do that since I want to allow users to add their own tags.

Are there any recommended speed enhancements specifically for using Semantic DrillDown?

I tried the following speed enhancements to no avail:
 * $smwgQEnabled=false;
 * $smwgQEqualitySupport=SMW_EQ_NONE;

I'm not sure if caching has been setup yet... would that improve the issue? I'm not very experienced and would prefer to avoid setting up PHP caching unless that would definitely fix the problem.

I am running:
 * Semantic Drilldown .0.8.3
 * Semantic Mediawiki 1.5.5 alpha
 * Mediawiki 1.17.0
 * PHP 5.3.3 (apache2handler)
 * MySQL 5.1.61

Thanks in advance for any help. SEE UPDATE ABOVE!!!!


 * Hi - the choice of browser really shouldn't have any effect, since all the performance-intensive stuff done by Semantic Drilldown is server-side. Also, SMW settings should have no effect (as you discovered), since SD does direct SQL queries, instead of going through SMW. You could try upgrading SD (and SMW) - I don't know if that will have an effect, but it couldn't hurt, and it's a good idea anyway. If that doesn't help, it could be that switching to combo boxes is the best solution, for now. Yaron Koren (talk) 02:29, 8 April 2012 (UTC)

Excluding a page from drilldown
Is there a way to exclude particular page from showing up within drilldown? Something like __HIDEFROMDRILLDOWN__ for pages? --Dusanson (talk) 13:49, 25 April 2012 (UTC)


 * No - out of curiosity, why would you want that? Yaron Koren (talk) 14:40, 25 April 2012 (UTC)


 * Pity. I ended up changing the template. Well, i'd need to explain more widely what i'm working on, briefly - we have two sets of pages with imported data: public, and the rest which is only visible to their owners. They can make them public after setting up an account, but before that their data shall not be part of drilldown. --Dusanson (talk) 16:38, 25 April 2012 (UTC)

Filter problems with namespaces
I have had problems with filters not returning results - error msg: (There are no values for this filter) is displayed.

It occurs when I have a local namespace defined. $smwgNamespaceIndex has been set, the ns label/value #defined and listed in $wgExtraNamespaces. The docs on $smwgNamespacesWithSemanticLinks say "Overwriting the following array"... so I assume that means to copy it, add additional namespaces and insert into LocalSettings.php (I have tried before and after the SemanticBundleSettings.php line).

I find that doing that breaks all filters (sometimes only some are broken until SMW_Refresh -ftpv & -v are done, then all don't work). If I change the list in SMW_Settings.php (and remove the list in LocalSettings.php) all is fine.

I have just tested it with MediaWiki 1.19.0, PHP 5.3.3, MySQL 5.0.77, Semantic Bundle (Version 20120327).

Am I missing something? Can that be reproduced elsewhere? Or should $smwgNamespacesWithSemanticLinks not be in LocalSettings.php?

Thanks for a bunch of great extensions! Bejay (talk) 07:55, 16 May 2012 (UTC)


 * Hi - if you go to a page in that custom namespace, that has properties defined in it, and click on "Browse properties", do the properties show up? If not, then this isn't a Semantic Drilldown issue. Yaron Koren (talk) 15:08, 16 May 2012 (UTC)

Spezial:BrowseData causes Fatal error after Update 1.18.2 to 1.19.0
After updating to MW 1.19.0 Using Spezial:BrowseData results in following error:

Fatal error: Call to a member function getArticleID on a non-object in /var/www/MyWiki/extensions/PageSchemas/PageSchemas.classes.php on line 265

My configuration:


 * MediaWiki 1.19.0
 * PHP 5.3.10-1ubuntu3.1 (apache2handler)
 * MySQL 5.5.22-0ubuntu1

and

Barpfotenbaer (talk) 12:46, 23 May 2012 (UTC)
 * Semantic Bundle (Version 20120327)
 * Semantic Forms (Version 2.4.2)
 * Semantic MediaWiki (Version 1.7.1)


 * This sounds like a bug in the Page Schemas extension - by the way, it's great that you're using Page Schemas. What's the category name? My guess is that it contains non-Latin characters. Yaron Koren (talk) 16:42, 23 May 2012 (UTC)
 * No category, starting at the top of the tree
 * ...?title=Spezial:BrowseData/Personenindex works, but does not show the grey category chooser box anymore.
 * ...?title=Spezial:BrowseData results in the error.
 * However, I discoverd something strange: I have a very similar setup on another server, with absolutely identical extensions, versions and LocalSettings.php. It differs only in PHP (version & configuration) and MySQL
 * MediaWiki 1.19.0
 * PHP 	5.3.3 (cgi-fcgi)
 * MySQL 	5.0.95
 * and everything seems to be fine there!
 * In total I have updated 6 SMW installations from 1.18.2 to 1.19.0. Four of these installations are on the same server. The both installations on the two different servers are doing well. But it is strange, that on the "big" server, 3 of 4 installations are affected by this error, but one single installation is doing very well! Every single installation does have absolutely identical extensions installed they do differ inside LocalSettings.php only in names, MySQL-configuration and user rights.
 * Barpfotenbaer (talk) 13:33, 24 May 2012 (UTC)
 * Strange! Maybe it's the MySQL configuration - MyISAM vs. InnoDB, latin1 vs. utf8, or something like that? Yaron Koren (talk) 15:06, 24 May 2012 (UTC)
 * I compared all databases, but all are type InnoDB. If not binary, only one database has some tables with utf8 charset, all the others are latin1 (if not binary). It must not be responsible for the problems. However a new strange thing occured. I installed 2 new mediawikis from scratch. The first one with 1.19.0, the second one with 1.18.2. And both are resulting in the getArticleID-"Fatal error", mentioned above. Thus, the bug actually must not have to do with 1.19.0!
 * But what about my configuration? Perhaps the error is caused by my php.ini or httpd.conf? Unlikely, because all four mediawiki-installations are using the same configs, the same extensions, ... The working one is neither the first, nor the last mediawiki, I installed. Barpfotenbaer (talk) 16:20, 24 May 2012 (UTC)
 * I have the same problem!
 * I have the same problem!

--Schubi87 (talk) 16:22, 25 June 2012 (UTC)


 * I've looked through the code, but I can't figure out what is causing this behavior. Is this happening on a public wiki anywhere? Because that would be helpful to see. In any case, it's easy to make this problem go away, for now - you just have to un-include the Page Schemas extension (assuming you're not using it). Yaron Koren (talk) 23:22, 25 June 2012 (UTC)


 * I could resolve the issue by enabling all rights for the database user. By default they are not enabled.--Schubi87 (talk) 10:44, 28 June 2012 (UTC)


 * That's good news, though very strange.... just to clarify: (1) you got the error message above ("Call to a member function getArticleID..."), (2) it only showed up when you went to "Special:BrowseData" without a category name, and (3) it went away when you added rights for the database user? Yaron Koren (talk) 14:49, 28 June 2012 (UTC)
 * (2) I just saw the message when I called Special:BrowseData without any arguments. 1,3 are correct. Maybe there was something else that influenced (3). --Schubi87 (talk) 16:10, 2 July 2012 (UTC)

Filter based on Namespace
Is there a way to have Semantic Drilldown filter by Namespace (I'm trying to get it to include pages from the Main namespace)

--Rosencrantz (talk) 18:09, 24 September 2012 (UTC)


 * No, there's no way to do that. Yaron Koren (talk) 18:17, 24 September 2012 (UTC)

No Results format for Googlemaps
I had set up a semantic browse data on mapped places. On my category page I had set  as per the Browse Cities example shown in the documentation. I had this working up until I upgraded to the letest version of Mediawiki 1.19.2 PHP5.2.17 SQL5.0.91 and latest SMW bundle

Now I get the following error message There is no result format for 'googlemaps'.

Backtrace:

Google Maps and Semantic Maps works everywhere else in the Wiki and I put the Validator/Maps and Semantic Maps in the right order in LocalSettings.php. In semanticbundlesettings.php I uncommented the $egGoogleMapsKey line (doesnt make a difference either way). If i just leave the format=maps I dont get an error just the page with the coordindates of the places not the maps themselves. Do I have a compatibility issue or a set up issue?--Paulreed (talk) 02:31, 26 September 2012 (UTC)
 * 1) 0 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/extensions/SemanticDrilldown/specials/SD_BrowseData.php(1093): SMWQueryProcessor::getResultPrinter('googlemaps', 0, Object(SMWQueryResult))
 * 2) 1 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/QueryPage.php(530): SDBrowseDataPage->outputResults(Object(OutputPage), Object(SkinMonoBook), Object(DatabaseSimpleSecurity), Object(ResultWrapper), 14, 0)
 * 3) 2 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/extensions/SemanticDrilldown/specials/SD_BrowseData.php(148): QueryPage->execute('Places')
 * 4) 3 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/SpecialPageFactory.php(476): SDBrowseData->execute('Places')
 * 5) 4 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/Wiki.php(263): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
 * 6) 5 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/Wiki.php(593): MediaWiki->performRequest
 * 7) 6 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/includes/Wiki.php(503): MediaWiki->main
 * 8) 7 /hermes/waloraweb070/b2209/moo.xxx/wikireedia/index.php(58): MediaWiki->run
 * 9) 8 {main}


 * I've seen that issue myself, and, if I remember correctly, both I and Jeroen De Dauw (the author of Semantic Maps) have looked into it, but without being able to figure it out, unfortunately. In any case, I'm pretty sure this is an issue in Semantic Maps. Yaron Koren (talk) 13:34, 27 September 2012 (UTC)

Filters not showing values
I set up a few filters, but they don't appear to register the values. I've tried several things but none seem to work including the different options to specify the included values and running SMW_refreshdata.

http://businessmodelproject.com/w/Special:BrowseData/Business

Any insight would be greatly appreciated.

MediaWiki    1.19.1 PHP    5.3.14 MySQL    5.5.21 SMW 1.7.1 Semantic Drilldown 1.2.2

CJGarner (talk) 13:46, 8 October 2012 (UTC)


 * Hi - it's because all your properties are of type "Text", which can't be filtered on. "Text" should be used only for properties that can have very long values - you should switch those properties to "String" instead (or, for the case of "Active Model", possibly "Boolean"). Yaron Koren (talk) 15:57, 8 October 2012 (UTC)


 * Yes. I switched the properties and everything worked perfectly. Thank you! CJGarner (talk) 16:03, 8 October 2012 (UTC)

In the Drilldown page, Is it possible to automatically hide filter that doesnt show any value because of previous select.
In the drilldown page when we select some values, some filters below doesnt show any values anymore... Is that possible to automatically hide this row or is this enhancement planned ?

Thanks,

Nicolas NALLET (talk) 18:29, 11 October 2012 (UTC)


 * No, unfortunately there's no such feature, and it's not planned. Do you think it would be a good idea? Yaron Koren (talk) 22:26, 11 October 2012 (UTC)

Hi, Yes it could be a nice feature because we could put a lot of filters and be sure to have the clearest DrillDownPage.

Another solution could be showing filters only if a value was selected in another filter. But it need more configuration in the category page.

What do you think ?

Thanks, Regards

Nicolas NALLET (talk) 18:25, 12 October 2012 (UTC)


 * Hi - for that, you can already use the "Requires filter" property, if I understand your question correctly. Yaron Koren (talk) 03:15, 15 October 2012 (UTC)

Hi, ok for "Requires filter" property, but it shows the new filter regardless the value selected previously. And some values has no values in the new filter posted and in consequence we have a filter without value... Idont know if I'm clear...

See U Nicolas NALLET (talk) 15:16, 15 October 2012 (UTC)


 * I get it - you want the 2nd filter to show up only if the 1st filter has been selected with certain values. Yes, there's no way to do that - that might be interesting. Yaron Koren (talk) 16:53, 15 October 2012 (UTC)

Yes you got it. And I think that it could be achieved by 2 ways :
 * Enhance the property (or build a new special property which could be named "require value in filter") "Requires filter" to require only one value of the filter to be selected and not anyone of the values of the filter.
 * Adding the rule : if "There are no values for this filter" the filter is completly hide

Both solution have the same results a narrower "drilldown zone" in the DrillDown page without empty filters, and thus more results directly visible at the bottom without nedding scroll.

I think the 2nd way is more simple both for programer and admin : he could put a lot of filters without being afraid of overload the drilldown with empty filters which will appear after the first value selected.

Anyway I thnink that that's not a priority enhancement. What do you think? Thanks and see U Nicolas NALLET (talk) 19:29, 15 October 2012 (UTC)

Wrong version?
I was about to write here that the filters no longer work in the latest version of SD, but now I see there may be an error in the documentation. The latest version according to the infobox is 1.2.4, but the download link leads to a version that claims to be v1.2.3 - which may not be compatible with SMW 1.8 (and so may explain the filter issue). Could someone put up the correct version? Cavila MW 1.19.2, MySQL 5.1.63, Php 5.3.3-7, SMW 1.8, SF 1.5.1 11:14, 21 January 2013 (UTC)


 * Oops! I had the wrong download link there for two months. That's pretty bad... hopefully it didn't cause too many problems. Thanks for letting me know about that; I just fixed it. Yaron Koren (talk) 14:06, 21 January 2013 (UTC)


 * No problem at all, as far as I'm concerned, and thanks for fixing this so quickly. Now the filters are working again rather smoothly. Cavila MW 1.19.2, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.1 12:09, 28 January 2013 (UTC)

Troubleshooting Semantic Drilldown after upgrade "(There are no values for this filter)"
After upgrading switching to php 5.3 from 5.2 and upgrading from mediawiki 1.18, smw 1.7 and all other extensions, including Semantic Drilldown from 1.2.2-- drilldown no longer works -- the Browse Data page is now useless. I'm just looking for next steps in the trouble shooting process.

Current Config
 * MediaWiki	1.20.6
 * PHP	5.3.25 (cgi-fcgi)
 * MySQL	5.5.30-30.1
 * Semantic Drilldown (Version 1.2.4)
 * Semantic MediaWiki (Version 1.8.0.4)

Problem Details
 * Every Filter just reports "(There are no values for this filter)" on Special:BrowseData. These filters used to work. I created new filters, they don't work. custom labels don't display.
 * Semantic properties work. All the basic tools for browsing semantic data in SMW, property pages list values, ask# works, etc.... SMW appears to work
 * all changes to semantic data ends up updating the data as one would expect.
 * I have tried disabling all extensions other than Validator, SMW, and Drilldown, with no effect on this
 * the MW db user has all required permissions for SMW 1.8.0.4
 * no errors show up when $wgShowExceptionDetails or $wgDebugToolbar are enabled.

And.. what might be the key to this:


 * a private facing MW install of 1.19.2 with Drilldown 1.2.2 and SMW 1.7 has also stopped functioning in the exact same way. it is on the same server.
 * a few hours after switching to php 5.3 from server default via forcing through .htaccess -- both SMW sites went down due to a new server config error on the part of the hosting service- essentially despite my .htacccess telling the site to use php5.3 the site was being forced to 5.2.17. They fixed it super fast after I contacted them, so they probably did something easy.

Any insights? anyone else run into this problem? any ideas for what I should be looking into? could this be a problem server-side? Is there something I can check or should ask tech support to check/fix? I am not really a server person and I have learned the hard way that for tasks that I cannot access, I need to spell out exactly what I need them to do/try -so specific ideas would be really helpful.... Thanks!

-- A.Sea.Arr (talk) 17:44, 12 June 2013 (UTC)


 * Hi - I just released a new version of Semantic Drilldown, 1.2.5, yesterday, that may fix this problem - please try upgrading to that. Yaron Koren (talk) 18:00, 12 June 2013 (UTC)
 * I was so excited to try the upgrade... but no change occurred. I'm not really sure where I should be looking to fix this. I've already tried going back down to 1.2.2 as well... -- A.Sea.Arr (talk) 21:48, 12 June 2013 (UTC)
 * Downgrading definitely won't work. How are you defining your filters? Can you paste here the contents of one of the non-working "Filter:" pages? Yaron Koren (talk) 23:03, 12 June 2013 (UTC)
 * Some Examples -- I just cut and pasted, and took out the extraneous details and added "code" and "nowiki" formatting for readability here. My filters previously worked. I've tried subbing in the enumeration allowed values to "Has value" for the filter with no result as well. All of the filters have plenty of material to work from and the SMW property pages list pages/values as one would expect. All only are on properties of type "enumeration" there are no dependencies on other filters. Top level category, one property filter for most cats. The fact that it stopped working in two MW installs, only one that has been upgraded to DD 1.2.4 (well, 1.2.5, now) makes me wonder if something could be wrong with our host's server configuration post move to php5.3.25? I just wish I knew enough on how to dig deeper or could pinpoint the exact point at which they stopped working.


 * --A.Sea.Arr (talk) 15:13, 13 June 2013 (UTC)


 * I don't know if PHP is involved, but in any case, "Enumeration" is not a type - could that be the issue? Also, I'm not sure if "Covers property" requires the "Property" namespace - you might try adding it in, just in case. Yaron Koren (talk) 15:16, 13 June 2013 (UTC)


 * First -- Thanks for your help! Second, some digging showed me that "Enumeration" was really just an alias for String -- which I see is now depreciated as of SMW 1.8. Its not working on the MW1.19 install with SMW 1.7, anymore either. Also, It's my understanding that type "text" can't be filtered on ... but that's the suggested replacement for properties of type string....  Does type "Page" still work with Drilldown? there are a couple of filters for Type Page, and even when changing the "Covers Property::Property:X" --- this didn't lead to success (on either install).  --  A.Sea.Arr (talk) 18:25, 13 June 2013 (UTC)

Type "Text" can be filtered on, starting with SMW 1.8, and with the latest SD. And yes, you can filter on "Page". Yaron Koren (talk) 20:23, 13 June 2013 (UTC)

Fatal error: Unsupported operand types in SemanticDrilldown.php on line 161
i cam getting this error: Fatal error: Unsupported operand types in extensions/SemanticDrilldown/SemanticDrilldown.php on line 161 am using the latest MediaWiki ver, and am installing the extension thru git.