Page MenuHomePhabricator

$smwgNamespace seems not to working in 1.9 beta-1
Closed, ResolvedPublic

Description

$smwgNamespace seems not to working in 1.9 beta-1

http://semantic-mediawiki.org/wiki/Help:Configuration#smwgNamespace

MediaWiki: 1.22.0rc3 (0e84337)
PHP: 5.4.17 (cgi-fcgi)

Semantic MediaWiki: 1.9 beta-1


Version: REL1_22-branch
Severity: normal

Details

Reference
bz57823

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:35 AM
bzimport set Reference to bz57823.
bzimport added a subscriber: Unknown Object (MLST).
Unknown Object (User) added a comment.Dec 2 2013, 12:38 AM

Not sure what you means by that (In reply to comment #0)

$smwgNamespace seems not to working in 1.9 beta-1

Looking at [1] which needs $smwgNamespace to be set correctly does not show any unusual behaviour, also unit tests [2] do work as expected.

[1] http://semantic-mediawiki.org/wiki/Demo:Berlin

[2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/tests/phpunit/includes/NamespaceExaminerTest.php

PS: Without a specific example as to why it seems that $smwgNamespace doesn't work, it will be difficult to expand the discussion on this topic.

Ok, you are right. I'm sorry.
Well, let's see:

If I am not wrong, we can't see $smwgNamespace behavior on semantic-mediawiki.org because $smwgNamespace is not set to a different value (it is used the default).

We can see the different $smwgNamespace behavior in semanticweb.org:

http://semanticweb.org/wiki/Special:ExportRDF/Semantic_wiki

where

http://semanticweb.org/Special:URIResolver/Mariano_Rico
becomes
http://semanticweb.org/id/Mariano_Rico

because $smwgNamespace is set to 'http://semanticweb.org/id/'.

What I am trying to say is that setting $smwgNamespace to a different value the RDF export continues to deliver 'http://.../Special:URIResolver/...

(sorry my English)

Unknown Object (User) added a comment.Dec 2 2013, 1:01 AM

$smwgNamespace and the URL resolver (Special:URIResolver/) are not related to each other. See [1].

http://semantic-mediawiki.org/wiki/Help:Pretty_URIs

Unknown Object (User) added a comment.Dec 2 2013, 1:04 AM

(In reply to comment #3)

$smwgNamespace and the URL resolver (Special:URIResolver/) are not related to
each other. See [1].

http://semantic-mediawiki.org/wiki/Help:Pretty_URIs

Sorry, I have redact my comments, I was talking about $smwgNamespacesWithSemanticLinks.

So, could you confirm the bug? :)

It's an old (but gold) feature.
I think it first appeared in SMW at 1.5.
http://semantic-mediawiki.org/wiki/Help:Configuration_1.5#smwgNamespace

Unknown Object (User) added a comment.Dec 2 2013, 1:42 AM

The only thing I can confirm (based on the commit history) is that non of the core-developers have changed any feature related to Special:URIResolver or $smwgNamespace since 1.8 which makes it unlikely to be an issue of 1.9.

PS: I'm still not sure I understand the exact nature of this issue (what is being expected and was is the deviation of the expected behaviour).

Ok. Without
$smwgNamespace = 'http://any-site.org/id/';
in LocalSettings.php, the the Special:ExportRDF gives URIs like
http://any-site.org/wiki/Special:URIResolver/Rudolph,_Sebastian
and this is the default behavior. This is fine.

With
$smwgNamespace = 'http://any-site.org/id/';
in LocalSettings.php, the the Special:ExportRDF gives URIs like
http://any-site.org/id/Rudolph,_Sebastian

But now, having
$smwgNamespace = 'http://any-site.org/id/';
the Special:ExportRDF continues providing URIs like
http://any-site.org/wiki/Special:URIResolver/Rudolph,_Sebastian

The problem is not in SMW 1.8 because semanticweb.org is using SMW 1.8 and they have Pretty URIs, as you noted in comment 3.

This feature is more important for those who uses triple stores, SPARQL endpoints and cares about linked data, URIs, etc.

As an old (and forgotten) feature, maybe Marcus could have a look at this issue. I think he wrote most part of the RDF export, right?

Unknown Object (User) added a comment.Dec 9 2013, 10:55 PM

Please run 'composer update' to retrieve the latests 1.9-beta. We deployed a unit test [1] that verifies the $smwgNamespace setting at the time SMW is installed [2] on the continues integration platform.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/tests/phpunit/system/InstallationSettingsTest.php#L47

[2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/build/travis/before_script.sh#L70

Thanks for the unit test, MWJames!
But, looking my configuration again, I found out what was wrong.

Apparently, this:

$smwgNamespace = 'http://any-site.org/id/';
enableSemantics( 'any-site.org' );

Was causing the problem. The correct way is:

enableSemantics( 'any-site.org' );
$smwgNamespace = 'http://any-site.org/id/';

When I removed

require_once( "$IP/extensions/Validator/Validator.php" );
include_once( "$IP/extensions/SemanticMediaWiki/SemanticMediaWiki.php" );

from LocalSettings.php (because installation with Composer doesn't need them), the "enableSemantics( 'any-site.org' );" and other config variables stayed there. So, later, when I put $smwgNamespace = 'http://any-site.org/id/';, I didn't realize enableSemantics was below it.

So, I am so sorry for this.
Hint: I think RELEASE-NOTES-1.9 should mention that enableSemantics( 'any-site.org' ); is not necessary anymore, right?

I am wrong again.

enableSemantics( 'any-site.org' );

Is still necessary. Without it the URIs become

any-site.orgSome_Page