Last modified: 2011-03-13 18:05:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21198, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19198 - SMW Comparators use sortkey instead of page name
SMW Comparators use sortkey instead of page name
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Markus Krötzsch
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-15 01:34 UTC by Christopher Lamb
Modified: 2011-03-13 18:05 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Christopher Lamb 2009-06-15 01:34:31 UTC
In semantic mediawiki queries, the comparators appear to act on a page's sortkey rather than the actual page name.

It's not clear to me if this is an error or if it is on purpose, but if it is on purpose, it does not appear to be documented in the user manual.

Take a hypothetical example: one page named "John Smith" and another named "Mary Smith." The page John Smith has the semantic property [[has mother::Mary Smith]]. This property has type page.

Now I want to have a semantic query and return all pages that have a mother that isn't Mary Smith. This should be done with {{#ask: [[has mother::!Mary Smith]]}}.

That query works fine and will not return the page John Smith, as expected.

However, if Mary Smith has a sortkey specified (i.e., {{DEFAULTSORTKEY:Smith, Mary}} somewhere in the page), this doesn't work. The query above will return the page John Smith, which it shouldn't do.

However, the query {{#ask: [[has mother::!Smith, Mary]]}} will not.

Therefore the comparator appears to be acting on the sortkey rather than the name of the page itself.

However, this is not the behavior without the comparator. {{#ask: [[has mother::Mary Smith]]}} will return John Smith whether or not there is a sort key on the Mary Smith page.

I have tested this on a private network. It is running mediawiki 1.15.0 and semantic mediawiki 1.4.2.

As I said, it's not clear to me if this is on purpose: I can see how it would be useful for alphabetic searching with > or < operators, for example. However, it seems that at least the not operator ought to behave the same way as the equality operator.
Comment 1 Markus Krötzsch 2009-06-15 08:04:12 UTC
It is true that all comparators act on sortkeys. This appears to be natural for the comparators that assume some ordering on the results (e.g. ::>), but I agree that it is potentially confusing for inequality. Since ::! is implemented like all other comparators, it also acts on sortkeys, so in a way this is a consequence of the design of the code. I agree that this needs better documentation.

On the other hand, ::> and ::! refer to the same values for all properties, which is rather useful for combining them in one query (Example: a US-based wiki might have a page to show all countries starting with letter U, but not the US). This would not be possible if both operators would refer to different values. It seems strange to specifically change the behaviour for ::! of Type:Page.

The real problem might be that one would actually like to have a dedicated "not same as" operator for pages, e.g. something like [[!Mary Smith]], where you really require some result to be unequal. The ::!, in contrast, only requires some unequal value to be present, i.e. it checks for the presence of some semantic information, while object inequality would check for the absence of some information (namely the absence of any hint that the object equals "Mary Smith").

More generally, it would be nice to negate query conditions. Are there any syntax proposals for this? (Using "!" as above would only work for single statements; maybe we should introduce a "NOT" that is used similar to "OR"?)
Comment 2 Markus Krötzsch 2009-11-03 16:33:14 UTC
Since there were no further suggestions regarding this issue, and since I do not see how to advance here without breaking other use cases and backwards compatibility, I close this with WONTFIX. However, I have extended the documentation to clarify the use of sortkeys with comparators.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links