Page MenuHomePhabricator

$smwgNamespacesWithSemanticLinks does not work for some namespaces
Closed, InvalidPublic

Description

In LocalSettings.php $smwgNamespacesWithSemanticLinks can be set to

$smwgNamespacesWithSemanticLinks = array(
NS_MAIN => true,
NS_TALK => false,
NS_USER => true,
NS_USER_TALK => false,
NS_PROJECT => true,
NS_PROJECT_TALK => false,
NS_MEDIAWIKI => false,
NS_MEDIAWIKI_TALK => false,
NS_TEMPLATE => true,
NS_TEMPLATE_TALK => false,
NS_HELP => true,
NS_HELP_TALK => false,
NS_CATEGORY => true,
NS_CATEGORY_TALK => false,
SMW_NS_PROPERTY => true,
SMW_NS_PROPERTY_TALK => false,
SMW_NS_TYPE => true,
SMW_NS_TYPE_TALK => false,
SMW_NS_CONCEPT => true,
SMW_NS_CONCEPT_TALK => false,
SF_NS_FORM => true,
SF_NS_FORM_TALK => false
);

And, unfortunately, it still does not work for for Category, Template, Property, and Form. Those are either semantically inaccessible, or otherwise problematic. For example, these simple queries will sometimes give a modification date, and sometimes not:

{{#ask: [[Template:+]] | ?Modification date}}
{{#ask: [[Property:+]] | ?Modification date}}

I have not been able to get forms to produce any modification date information, using a similar query:

{{#ask: [[Form:+]] | ?Modification date}}

Semantic mediawiki completely breaks on category wildcards, by showing every page in the wiki, not just the categories:

{{#ask: [[Category:+]] | ?Modification date}}

A workaround for this bug is to use DynamicPageList (DPL). It is a miserable substitute for the powerful semantic features of SMW that are supposed to work. However, several people have had to turn to it until SMW works fully.

http://smw.referata.com/wiki/Add_page_metadata_properties_to_a_page_(using_DPL)

http://www.mediawiki.org/wiki/Extension_talk:DynamicPageList_(Wikimedia)#Feature_Request:_DPL_query_with_SMW_properties

In addition, SMW persistently shows deleted pages, which is a related bug that I'll post separately:

http://semantic-mediawiki.org/wiki/Help_talk:Selecting_pages#Filtering_out_deleted_pages.3F


Version: unspecified
Severity: major

Details

Reference
bz29891

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:29 PM
bzimport set Reference to bz29891.

Relax: the reason that [[Category:+]] does not work is simply that it is ambiguous with SMW's way of searching for pages in the category called "+". Since this is not a valid page, the query ends up having no conditions and all pages are returned.

To use namespace wildcards for namespaces that already have a meaning in SMW query syntax (Contept: is another one), simply add an initial ":", i.e. [[:Category:+]] should work. In general, the ":" can always be added to be on the safe side. Maybe one could have a special tweak in the parser to recognize "Category:+" since it would not be a useful category query anyway.

The missing of values for "Modification date" is independent of this. SMW has to inject this date into the editing process, and (as with all data) it is only available if the page has been saved (edited) since SMW was activated (with semantics enabled for that namespace). Just enabling the semantics for some hitherto disabled namespace will not add new entries to the database. A refresh run (see Special:SMWAdmin) can be used to complete/update the data for all pages. It could also be that there are specific problems with Modification date since it is handled in a special way different from other properties. These issues need to be separated to allow for further investigation. I suggest to make specific bug reports on these points and close this report now (since the main issue seems to be fixed by a combination of prefix ":" and refreshing pages).

Thanks for the information. I seem to have misunderstood what was happening, and interpreted it as a bug. If I can remember what documentation I was reading while fiddling with this, I will check to see if it can be made more clear that additional steps are required when adding or removing namespaces.

Also, I have extracted two distinct bugs from your suggestion, and added them here:

https://bugzilla.wikimedia.org/show_bug.cgi?id=29900
https://bugzilla.wikimedia.org/show_bug.cgi?id=29901

I haven't isolated any other problems with the Modification date property, so unless I notice a problem distinctly related to that, I don't think there are any bugs in it that have led to the creation of this bug report.

I agree that this bug report should be closed. I changed the status from FIXED to INVALID. Please change it if that isn't correct. I couldn't find a detailed explanation of the different statuses and when they should or should not be used.

I isolated this distinct bug with the modification date property, and possible solution: https://bugzilla.wikimedia.org/show_bug.cgi?id=29909