Extension talk:Semantic Drilldown

Bugzilla
Is bugzilla component created for it yet? Should people submit bugs to SF component while it's being created? --Sergey Chernyshev 22:59, 10 December 2007 (UTC)


 * Oops, I had bad instructions for submitting bugs before; it's fixed now. No, there's no Bugzilla component yet for SD, but most likely there will be soon. Yaron Koren 00:35, 11 December 2007 (UTC)

Bug report and feature request
Just installed it. For some reason the filter shading is not showing up.

Also, all my categories are showing up on the top bar. I know that's how it's supposed to work, but my top-level categories include things like Help and Templates. Maybe there should be a way to set what should be showing up as categories? I guess the best way to do that would be to have an attribute set on the category's page. That does add a level of complexity. Maybe the attribute can be placed on categories that are excluded. --Tosfos 05:40, 12 December 2007 (UTC)


 * For filter shading - that should be specified in a CSS file, called "SD_main.css". My guess is that the URL that's specified for that file isn't readable, for one reason or another. Can you look in that page's source code, then try going to that CSS file in your browser, and seeing if that's the case?


 * Having an 'exclude from drilldown' attribute/property isn't a bad idea. Out of curiosity, though, why do you have a "Templates" category? If you have SF installed, you can just use 'Special:Templates' to see the whole list. Yaron Koren 15:18, 12 December 2007 (UTC)


 * You're right. That file was blank somehow. A reinstall fixed the "bug." (I had tried a reinstall but I foolishly used the same archive as the first install. Sorry.)


 * As for why I have a templates category, the truth is it's a holdover from my pre-SF days. But I still like it. I have many templates that aren't defined by forms, such as utility templates, and they're all neatly divided into sub-categories. --Tosfos 19:29, 12 December 2007 (UTC)

Classifying as "other"
I'm wondering how the extension decides what to list explicitly and what to list as "other." I've figured out that for a relation, if the related page doesn't exist, that relation is classified "other." Why? Also, I had one relation where everything was classified "other" until I put a "Gets values from category" in the filter. --Tosfos 01:10, 13 December 2007 (UTC)


 * Hi, the explanation for how the filter gets its values was lacking. I added the following to the documentation: 'If neither "Gets values from category" nor "Has value" are defined for a filter, the extension will assume that the property for this filter is an enumeration, and get its values from that property's "allowed values".' Does that make sense? For the first case, presumably you had "Gets values from category" set - pages that don't exist yet don't belong to a category. Yaron Koren 17:28, 13 December 2007 (UTC)


 * Sounds right, though I haven't tested it yet. The explanation doesn't list what happens if it doesn't fit the enumeration's allowed values. Thanks. --Tosfos 19:40, 13 December 2007 (UTC)


 * The documentation is admittedly skimpy - I added more of an explanation to the "Description" section. Please let me know if it makes sense now. Yaron Koren 21:34, 13 December 2007 (UTC)


 * I think it's good for a 0.1 version of documentation :). --Tosfos 02:17, 17 December 2007 (UTC)

Filters on filters
I know it's a little early for feature requests, but I'll put it here for future consideration.

I think it would be nice to be able have sub-filters of filters. A sub-filter would be a filter that doesn't show up as an option until its parent filter is selected. The extension already does this with sub-categories: the sub-sub-categories don't show up until the parent is selected.

Here's an example: Say in the Sources category, you wouldn't only want to filter it based on "country" but also based on "state" (or "city" or "province"). You wouldn't want "state" to show up as a filter until "country" was selected because it would show states of every country in the world. Since each state can only be in one country, it's much simpler to have the user first select the country and then the state.

I tried to think of a simple implementation. Perhaps each filter's definition can have an optional attribute called "requires filter" or something like that. In the above example, the Filter:State page would say requires filter:=Filter:Country. Under the current implementation, once the country is selected, only states in that country would return values, so states in other countries wouldn't show up.

I have more to say on the subject, but I would like to hear your opinion first. Thanks. --Tosfos 03:07, 17 December 2007 (UTC)


 * That's a great idea, and I believe someone else requested it early on. Thinking about it now, it probably wouldn't be hard to implement at all - it might even go into the next version. That also reminds me that I should get a Bugzilla "component" added for Semantic Drilldown... what else did you have to say about this proposed feature? Yaron Koren 17:21, 17 December 2007 (UTC)


 * I may be the one you're remembering. I was suggesting something similar: There are instances where it would make more sense to not show all the potential criteria for the higher levels of a drilldown... Otherwise wikis with a lot of criteria could get very cluttered at the higher levels.


 * Note that a side-benefit (if you consider it a benefit) of the proposed implementation is that it also implements the above suggestion. It would be possible to have one filter require a completely unrelated filter to be selected before being available. This raises another possibility. If I had, for example, three total filters, I might want to have the third filter show up after either of the other two are selected, etc. Implementing this might complicate things and I'm not sure it's so necessary. What do you think?


 * Another issue: If this feature is implemented, it wouldn't make sense to only allow filters on filters but not on sub-categories, IMHO. The same way I might want a filter not to show up after another filter was selected, I may not want it to show up until a certain sub-category is selected. Under the current implementation, filters can only be placed on a top-level category. But I may have five sub-categories, each one having its own unique filter. It would make more sense to have each of those filters on its related sub-category, rather than putting all five on the top-level category (which would also make the top-level filtering rather complicated, as above). I realize that under the current implementation it makes sense to place all of them in the top-level category. Since all five do show up as a top-level filter, it would be confusing if they all came from different places. I think that's all (for now). Thanks again. --Tosfos 02:57, 18 December 2007 (UTC)


 * Yeah, it might have been you, now that I think about it. Although maybe it was more than one person. As to your other suggestions: having a "either/or" dependency for filters seems like it would introduce a lot of complexity, both for administrators and for users trying to figure out the rules of the system. I also don't know when it would ever be useful. As for filters for subcategories - that sounds like a more useful feature, and it starts to resemble my original design for the extension, which allowed more flexibility. I'll think about which (or both) of these to add in to the next version. Yaron Koren 04:39, 18 December 2007 (UTC)

Problem after install
I've just installed version 0.3.4 onto my system. I'm running mediawiki 1.8 with Sematic 1.0 and MySql 5.045a.

I'm getting the following error when when I click on Browse data:

Database Error A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "". MySQL returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's' ORDER BY cl.cl_sortkey' at line 3 (localhost)". I do have properties, templates, categories and forms setup and working. Any ideas? Thanks!


 * Oh, that's not good. Try adding the line "$wgShowSQLErrors = true;" anywhere to your LocalSettings.php file. That will un-hide the SQL query, which should give a better idea of what's going wrong. If you still don't know, please put the SQL query here. Yaron Koren 17:46, 1 February 2008 (UTC)

Hi. Thanks for the fast response. The error is:

SELECT p.page_title, p.page_namespace FROM `categorylinks` cl 		JOIN `page` p on cl.cl_from = p.page_id 		WHERE cl.cl_to = 'ADP's' ORDER BY cl.cl_sortkey

from within function "". MySQL returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's' ORDER BY cl.cl_sortkey' at line 3 (localhost)". The error is obviously with the ' character. I have a category called "ADP", but nothing called "ADP's". Hmmm. Needs a \ in the query perhaps?


 * Hi, okay, you've found a bug in Semantic Drilldown - it can't handle category names that have an apostrophe in them. This will be fixed in the next version; for now, I'm pretty sure you do have a category called "ADP's"; if so, you can just delete it, and take care of the problem on your wiki. Yaron Koren 18:04, 5 February 2008 (UTC)

Aha! I had an old unused category called "ADP's". Of course, as it wasn't used it did not show up in the main Category list. I've deleted it and browse data now works. Great plugin :)

My Patch
Because I had some Problems with the CREATE INDEX SQL I made a small patch, also fixing the bad translation of Namespaces in German. Here it is. Index: includes/SD_Filter.php

=
====================================================== --- includes/SD_Filter.php	(revision 33871) +++ includes/SD_Filter.php	(working copy) @@ -102,7 +102,7 @@ 			FROM $table_name WHERE $property_field = '$query_property'"; 		$dbr->query($sql); -		$sql = "CREATE INDEX sdfv_subject_id_index ON semantic_drilldown_filter_values (subject_id)"; +		$sql = "ALTER TABLE semantic_drilldown_filter_values ADD INDEX sdfv_subject_id_index (subject_id)"; 		$dbr->query($sql); 	} Index: languages/SD_LanguageDe.php

=
====================================================== --- languages/SD_LanguageDe.php	(revision 33871) +++ languages/SD_LanguageDe.php	(working copy) @@ -20,7 +20,7 @@ var $m_Namespaces = array( 	SD_NS_FILTER		=> 'Filter', -	SD_NS_FILTER_TALK	=> 'Filter_talk' +	SD_NS_FILTER_TALK	=> 'Filter Diskussion' ); } Index: specials/SD_BrowseData.php

=
====================================================== --- specials/SD_BrowseData.php	(revision 33871) +++ specials/SD_BrowseData.php	(working copy) @@ -93,7 +93,7 @@ 		$dbr->query($sql); // create an index to speed up subsequent queries // (does this help?) -		$sql2 = "CREATE INDEX page_id_index ON semantic_drilldown_values (page_id)"; +		$sql2 = "ALTER TABLE semantic_drilldown_values ADD INDEX page_id_index (page_id)"; $dbr->query($sql2); }

Maybe you can test this Version, I think it does the same but maybe it denies problems with the CREATE INDEX Statement. DaSch 22:37, 24 April 2008 (UTC)


 * Hi, thanks for the patch, I'll add it in to the next version. Out of curiosity, what was the problem with the "CREATE INDEX" call? Yaron Koren 14:39, 25 April 2008 (UTC)


 * I think that many hosting provider does not allow this action so that I got an access denied Error on the BrowseData Special Page. DaSch 18:39, 25 April 2008 (UTC)