Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set up pretty URIResolver #26

Closed
kghbln opened this Issue Mar 6, 2017 · 14 comments

Comments

Projects
None yet
2 participants
@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Mar 6, 2017

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

What I have done:

Added the following lines to the VirtualHost on the respective spots:

Alias /wiki /var/www/html/02310/w/index.php
RewriteRule ^/id/(.*) /wiki/Special:URIResolver/$1 [L,P]

Added the following line to "LocalSettings.php" to the respective spots:

$wgUsePathInfo = true;

Probably this setting is not needed since short URLs work without this setting which is only required under certain circumstances.

$smwgNamespace = 'https://www.semantic-mediawiki.org/id/';

As a result "Special:RDFExport" adds:

<swivt:Subject rdf:about="https://www.semantic-mediawiki.org/id/Karlsruhe">

However https://www.semantic-mediawiki.org/id/Karlsruhe redirects to Main_Page since there is not accessible page at id/Karlsruhe. On the other hand https://www.semantic-mediawiki.org/wiki/Special:URIResolver/Karlsruhe redirects to https://www.semantic-mediawiki.org/wiki/Karlsruhe.

I am actually not sure what the expected behaviour of this setup is meant to be in the first place. As a human I still would like to access the Karlsruhe page via "https://www.semantic-mediawiki.org/wiki/Karlsruhe" instead of "https://www.semantic-mediawiki.org/id/Karlsruhe" no matter what we are doing here.

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

@mwjames Hmm ...?

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

I can imagine that I perhaps added the redirect rule too late meaning that the preceding ones already trigger the page to be delivered at "https://www.semantic-mediawiki.org/wiki/Karlsruhe" instead of "https://www.semantic-mediawiki.org/id/Karlsruhe".

From my perspective the expected result should be that humans access via /wiki/ while machines access via /id/.

@mwjames

This comment has been minimized.

Copy link

mwjames commented Jun 8, 2017

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

@mwjames Thanks for the info. Now I understand the expected behaviour. So the first part is working and the third part. What is not working is the redirect to Special:URIResolver. I will have to investigate this.

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

Yeah, something is borked, the rewrite rule

RewriteRule ^/id/(.*) /wiki/Special:URIResolver/$1 [L,P]

has no effect whatsoever, even if I move it to the first position so it gets considered first. Since this tip is ten years old...

@mwjames

This comment has been minimized.

Copy link

mwjames commented Jun 8, 2017

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

On the http vs. https issue, [...] The web server has to have some rules that forwards it to a matching resource so that http://example/org/id/Foo and https://example/org/id/Foo are equivalent, canonical, and protocol agnostic.

Well this is certainly the case and additionally since $wgServer is not protocol relative $wgCanonicalServer does not need to be set.

In a triple store http://example/org/id/Foo is used as identifier

Ah so back to what it was before on sandbox.

@mwjames

This comment has been minimized.

Copy link

mwjames commented Jun 8, 2017

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

For a tangential reference point, see "Consider switching to HTTPS for Wikidata query service links" [0].

The same battles all over the place. ;)

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

The original idea to switch smw.o was to provide a wiki which uses this more compliant identifier and setup. However this results into different identifiers than before and since the redirect from the identifier is not even working at the moment. I still thing we should deliberately break to have a working example rather than having no example at all, i.e. revert to what it was before.

@kghbln

This comment has been minimized.

Copy link
Member Author

kghbln commented Jun 8, 2017

I finally got this act together. It's backwards incompatible but what are ten years in comparison to the eons which still lay ahead.

@kghbln kghbln closed this Jun 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.