Summary: Add comparators for "greater than" and "less than"
           Product: MediaWiki extensions
           Version: any
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: Semantic MediaWiki

Request: please add the following new comparators: “less than” and “greater

A] Redefine comparators < and > to fit their mathematical meaning: “less than”
and “greater than”
B] Add a new notation for the original comparators “less than or equal” and
“greater than or equal”. The notation itself could either be the actual
characters (Unicode 2264/Extended ASCII 243  ≤  and Unicode 2265/Extended ASCII
242  ≥ ) or their two-characterASCII approximations (<= and >=) or something
else. People with knowledge of code pages and MW parsers may say something
intelligent about this
C] SMW might need a parameter for backward compatibility with the original <
and > comparators: $smwComparatorOldBehaviour. Reason: if one already has a
wiki and it uses < and >, the new style alters the behaviour of existing
queries with < or >. Admins of these wikis could set
$smwComparatorOldBehaviour=true. This would have the effect of disabling the
new “greater than” and “less than” comparators, and the parser would treat both
< and ≤ the same (“greater than or equal”), meaning the wiki could start using
≤ explicitly, eventually switching over  to the “new” behaviour once all
existing queries are corrected. After setting $smwComparatorOldBehaviour=false,
SMW would start parsing < as “less than” and ≤ as “less than or equal”. It can
also be argued that the parameter should be named $smwComparatorNewBehaviour,
or $smwUseGreaterThanAndLessThanComparators, etc. I propose the
$smwComparatorOldBehaviour name, so that we can use it while we need, and in
the future (e.g. in the year 2099) can declare the the parameter deprecated,
when we believe that no wiki on earth runs in the counter-intuitive Comparator
Old Behaviour mode.
D] The backward compatibility parameter should get a default value. It can be
argued that the default setting for $smwComparatorOldBehaviour should be
false, so that from now on every new wiki is always in new behaviour while we
still can accommodate admins of existing wikis (but there's an increased risk
of incorrect queries when admins of existing wikis fail to set/correct the
true, so that correct querying for existing wikis is ensured (but there's a
great risk of new wiki's not switching to the new behaviour)
true for now, and false in a later version of SMW, to have people get used to
the idea while not forcing anything.
I personally vote for the first option, with a clear warning in the release

Background: As described in the Semantic MediaWiki online documentation, the
SMW comparators are:
> and <: greater than/less than or equal
!: unequal
~: «like» comparison for strings (disabled by default) 
Ths does not readily allow for disjunct selects. Example: suppose property
“Foo” is of type number. Ideally, you would like to be able to select (with
“mathematical” comparators instead of SMW comparators):
a)   [[Foo::< 10]] (less than 10)
b)  [[Foo::>=10]] (10 or greater)
However, since the first comparator does not exist, a strict disjunct selection
under SMW looks like this
c)  [[Foo::< 10]][[Foo::!10]] (less than 10)
d)  [[Foo::>10]] (10 or greater)
Technically this works, but the notation is counter-intuitive.

Furthermore, the fact that > is “greater than or equal” and not simply “greater
than” can lead to unpleasant situations. Consider a property “maturity” with
allowed values 1, 2, 3, 4, 5, and 9. When selection all values in the range
1-5, you must use [[Maturity::<9]][[Maturity::!9]] for “everything below 9”,
instead of something like [[Maturity::<8]], since 8 is (currently) not an
allowed value; the notation inside a query would yield the famous

Discussion in #semantic-mediawiki and/or on the wikipage above most welcome

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to